Have you ever walked into a room to get something and the moment you got there you forgot what it was that you wanted?

That memory glitch is caused by a refresh in your working memory that happens when you enter a new space or environment. Apparently the evolutionary algorithm at work in humans developed this way to increase your situational awareness and keep prehistoric you from becoming a sabretooth snack. The little brain degaussing you get when exiting the cave actually applies to any new environment, even if it’s just passing through a doorway, any doorway, like the ones in your home. So what was once a feature is now a bug. It’s not terribly bad as bugs go, unless the reason you went into the kitchen was to get the fire extinguisher. But it is a bug now. 

This is your first clue as a developer that environment is everything. Environment is the most important thing because where your application will reside is more important than what it does, if you want it to work right and keep working.

The environment is where the application will reside and run, which will show how it is intended to be used. We can determine the environment by how it interacts with data, people, and physical constructs. The following should be determined to classify the environment:

1. Which specific operating systems will the system be designed to run on?

2. Will it be designed for specific hardware?

3. Will it be designed to run from specific physical locations because it will require a specific type of connectivity, or can it be run from anywhere?

4. Will it be designed for mobile access and connectivity?

Designing for a specific environment allows you to take full advantage of that environment and write extremely secure code. If you haven’t noticed, the same application coded in the same language will have different vulnerabilities on different architectures and operating systems. That’s because, despite the security measures taken in developing the code, the act of making it portable exposes it to different environments — different libraries, different error handling schemes, and even different means of human interaction. So creating controls for one environment may end up being a hindrance in a different OS.

Take a look at the National Vulnerability Database for any of these cross-platform applications and you’ll find vulnerabilities in the same version of the application that affect one type of OS, but not another. There’s a reason for this. It’s called the environment.

Now, to be fair, cross-platform programming languages and compilers are getting really good with consistency here. Which is great for developers trying to keep it together in this ever-expanding world of tech choices. However, the ever-exploding growth of platforms and choices of environment for each operating system is affecting how it all works together, especially in terms of security controls. And if you’re developing security applications that provide security controls, it gets even worse. While you can expect that some types of security controls will work on one type of OS, some controls will not even work on slight variations of the same OS.

Kind of like how a small genetic change in hemoglobin both causes sickle cell anemia and protects against malaria. In a malaria-infested environment, where the genetic change first took place, sickle cells protected the human. But in a different environment with no exposure to malaria, it’s a deadly genetic disease in itself that greatly shortens life expectancy. The difference between security (the cells fighting malaria) working and not working is the environment.

Scope Interactions to Find Your Attack Surface

Before you begin to develop, figure out your environment. This helps you make your scope — and all security begins with a scope.

The scope describes the environments on or in which the application will operate and the interactive points of the application. And by interactive points we literally mean all parts of an application that interact with anything that’s not the application itself.

It’s the scope that needs to be secured, but it may extend past what you can control if the application requires interactions beyond itself. Which, today, is pretty much all applications you will ever develop. Even if your application could lock in secured versions of libraries, memory reads, and system calls, you can’t control what’s happening beyond the system over the network. Something as simple as domain name resolution is not in your power to control and yet can be so devastating to the security of your application. In security terminology we have a word for that: "frustrating." Well, really there’s another word for it that also starts with an F.

The scope is the foundation for determining the application's attack surface, which is the unprotected or uncontrolled areas of the application which allow it to be misused or maliciously controlled. You find those areas by finding all the interactions. Then you look what controls exist for each interaction. Where and how the interactivity takes place will determine the areas where controls need to be focused. You can even draw a map of these interactions (and probably should if your application is longer than 100 lines).

Now you might be wondering why you are going through this trouble. Because security starts with understanding. Hackers are able to make systems and devices do what they want by understanding how they work more profoundly than the developers who made them. So while knowledge may be power in politics, in security we go beyond knowledge to recognize that understanding is raw strength.  And it’s understanding which we can use to create or destroy.

So, before you write a single line of code it’s important to scope interactions. This way you know what your attack surface looks like and can address it.

To ease the pain, start answering these questions before you start to code:

1. What parts of the application accept user input through a keypad or other such input devices?

2. What parts of the application accept user or system input through a network device or connection?

3. What parts of the application will be storing or reading data (even temporarily) to a permanent location like a hard drive or other permanent, removable media?

4. What parts of the application will be storing or reading data from a distant location (DNS, cloud, server array, website, peers, etc.).

5. What parts of the application will be storing or reading data in RAM?

6. What parts of the application will be interacting with peripherals (printers, sensors, etc.) over peripheral and wireless ports such as USB, AUX jack, Bluetooth, Serial, etc. (and note if it's one-way or bi-directional)?

7. What parts of the application will be storing or interacting within the framework of another application (a web browser, client, virtual system, sandbox, etc.)?

After that fun exercise, you’ll still want to understand the information the device interacts with. That will help you determine which and how many controls are required to protect it while it is operational.

1. Will the application require the storing of personal or legally confidential information such as financial or health information?

2. Will the application require the storing or transacting with sensitive or confidential information in the form of logs, debugging, crash dumps, etc.?

3. Will the application be collecting or transacting with information which can personally identify a person through an aggregate of different data (metadata)?

4. Will the application interact with machinery or industrial systems that can impact the health or safety of workers?

5. Will the application interact with other systems in an automated manner for which established thresholds exist or contextual limitations for safety purposes in case of errant or runaway interactions (like stock exchange transactions or medical dosing)?

Address these things and you have a solid scope and have begun to understand your attack surface.

Quiz – answer in the comments section and gain the respect and envy of your peers!

1. How does the environment affect an application?

2. If the application stores data to a logfile, is that an interaction for your application?

3. What do hackers analyze from an application to figure out how to take control of it over the network?

About Pete Herzog

Pete knows how to solve very complex security problems. He's co-founder of the Institute for Security and Open Methodologies (ISECOM). He created the international standard on security testing and analysis and Hacker Highschool.

Comments (0)

Please Post Your Comments & Reviews

Your email address will not be published. Required fields are marked *

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.