Published on
This post was written by Chris Romeo during his tenure at Security Journey.
When you build a skyscraper, how important is the foundation? It's crucial. Built on a weak foundation, even the most luxurious skyscraper will fail over time. The same is true for your application security program. You must build a solid foundation of application security knowledge, experience, and tools to ensure that the applications or products you build are secure. You must embed the six foundational truths of application security within your development lifecycle.Application security has one overarching foundational lesson that every organization needs to apply: Build security in instead of bolting it on. The build-in versus bolt-on decision is as old as security itself. When security is bolted on, it becomes an afterthought, pushed off until after the product ships. To properly build application security in, you must embrace it within each step of your development process.The following six lessons provide a strong foundation for your application security program. Within the world of application security, there are hundreds of items that could be added to this list, but in the interests of time and efficiency, the list that follows addresses only the items that provide the best return on investment and the strongest foundation. (If you disagree or want to add one, do so in the comments below.)
1. Don’t trust user input—ever
Users are not bad people—or are they? Unfortunately, good users get lumped in with the bad apples. The software that you write must take input from somewhere. Software without input is just a loop to nowhere. The problem is that most programmers trust the source of the input and implicitly trust all data entering their application. This is a flawed approach. Bad people send input to your application just as good people do. The bad people want your application to do something you did not intend.
When attackers discover a cross-site scripting vulnerability in your web application, they uncover a place where you accept input (perhaps via a form field) and do not validate that input to ensure that it is JavaScript-free. That JavaScript input becomes output and results in an attack being either reflected into a legitimate user’s browser or stored up and unleashed on future visitors to your application.
Tip: Perform input sanitization for ALL input, regardless of where it came from and how much you think you trust the source. Trust no one.
2. App sec, shift left (in the dev lifecycle)
A secure development lifecycle (SDL) is a crucial process for your business. The SDL defines the process and tools required to ensure that every application you release has applied the necessary steps to maximize its security. Your SDL is an overlay to a more complex development process.
The more security decisions you push to the left in your lifecycle, the cheaper application security becomes. The National Institute of Standards and Technology (NIST) shares some advice (PDF) in “The Economic Impacts of Inadequate Infrastructure for Software Testing,” by stating that the earlier you find a defect in your lifecycle, the cheaper it will be to fix. A defect discovered in the requirements phase costs 1x to fix, versus a defect found post-release, which costs 30x to fix. This additional cost is due to all the rework that must occur after the fix is made. This advice seems like common sense, but it is not always so common.
Tip: Embrace security from the beginning of your process and move application security left in your cycle. It costs less in the long run.
3. Default and hardcoded credentials are the enemy
A default credential is a password or cryptographic key that is the same for all instances of your application or, worse, all versions of a specific product. If you use a default credential and it becomes publicly known, bad people could access any running instance of your software, regardless of whose network it is deployed within.
A double whammy is to use a default credential and then hardcode it. If a credential is hardcoded, there is no way for the administrator to change the credential. A static, unchangeable password or key is a recipe for disaster.
Developers use default credentials because they are easier then implementing a secure credential store that is unlocked at boot or runtime for a product. "Easier" in this case results in less development time but more risk for the product and the end customer. Eliminate default credentials to secure all of your users.
Tip: Architect your product to force a password change during installation, and do not allow administrators to continue until they have chosen their own hard-to-guess password. Use a secure credential-storage system for your applications.
4. Responsibility for third-party software belongs to you
We are in the golden age of open source, when you hardly have to develop anything on your own. Open-source libraries and application frameworks provide common code that saves development cycles and standardizes your approach. Even Stacktrace code snippets count as third-party code, since you may paste a stacktrace dump into a code module with very little change.
When you import third-party software, you are taking ownership for that code within your product. Third-party software suffers from the same potential vulnerabilities your own code suffers from. You must perform testing on third-party code as if you wrote it yourself. You must also update third-party code. Open-source software does not auto-update, and many products across the Internet suffer from running ancient versions of open-source software that have been forgotten about.
Tip: Own all your code and care for it, regardless of whether it came from your brain or the Internet. Define a schedule to review and update any third-party software contained within your application.
5. Threat modeling reduces logic flaws
Threat modeling is the process of looking at a design with a keen eye toward security and uncovering how bad guys could potentially attack it. Threat modeling causes you to analyze the design of your feature, component, or even your entire product. Threat modeling should happen before you ever write a single line of code.
Threat modeling is done by the security team, who note each available interface and dream up ways to compromise based on the interface. The beautiful thing about threat modeling is that you do not ever have to craft exploit code. The threats are theoretical to help you pinpoint areas in the design that require a change to bolster security.
Threat modeling begins with a diagram because a picture is worth a thousand words. The picture uses data flow diagram pieces, including a process and data store. The act of drawing the picture assists the developer with thinking through how a design will actually work. Once the diagram is sketched, then the security analysis begins.
Your goal with threat modeling is to first teach it to your developers and then, over time, grow it into an ingrained behavior. True magic occurs when developers stop considering threat modeling a separate activity and perform security analysis organically.
Tip: Build the habit of doing developer threat modeling. Threat modeling is basic application security hygiene.
6. The greatest application security tool: Knowledge
Knowledge is the greatest tool available. When you prepare your developers and testers with the life lessons of security, you set them on a path toward squashing vulnerabilities early in the process. Application security tools are crucial to the success of any SDL, but their benefit is greatly diminished in the hands of an untrained engineer.
As legendary software engineer Grady Booch said, “A fool with a tool is still a fool.” This may be a bit harsh, but it does crystallize the fact that you need engineers to be knowledgeable in all the fancy application security tools you are providing in your process.
Tip: Teach your engineers application security, and then provide the tools to optimize.
Keeping them honest on app sec
If you apply these six foundational application security truths to your organization, you will improve not only your products, but also the people that build and test those products for you.
Image credit: Flickr
Read more from:
Application Security