PASTA Process for Attack Simulation and threat analysis (PASTA) Risk-centric Threat Modeling

Castle under siege
(Source Wikipedia)

Information security is about protecting digital assets from threats, software security is about designing and implementing software that is not vulnerable to threat agents seeking to exploit design flaws and bugs to compromise digital assets. Traditionally software security has been driven by the need to identify vulnerabilities with specific tests such as static source code analysis and fix them prior to release software products in production. Today this traditional defensive approach toward software security security cannot cope with increasing level of sophistication and impact of cyber-threats such as financial fraud and massive compromises of confidential data. I therefore advocate we need a new approach in software security that considers the attacker perspective while designing and implementing software. Let's start this new approach by considering threats and attacks while designing and implementing security controls such as setting security requirements. Let' s design, implement and security test new countermeasures so that the software is both threat resilient and attack proof. This blog is about educating people on how to write secure software and to manage the different risks of insecure software. Security engineering and risk management are part of the solution of secure software and these are not only responsibility of software developers but the software organization as a whole that includes application architects, information security officers, chief technology officers, risk managers and least and not last business owners. Software security requires collaboration between engineering and security teams. It requires business and risk managers to together seeking to improve engineering processes and minimize risks. Software security is not the end goal but a process that allows to reduce risks to a level that the business is willing to accept.  Software security is more journey than a destination, it is an on going mission and an opportunity to reduce risks to the business through continuous process improvements. Indeed we made improvements in software security. For example, the average software developed today has fewer number of vulnerabilities than had in the past,  say six, ten years ago. This is due to the availability of better tools for testing software vulnerabilities and to the effort of security vendors and organizations  whose mission has been improving the security of web applications like OWASP. Nevertheless, despite the progress made in software security, we are far from writing and building software that can be considered resilient to today's threats and attacks. There is still a lot of work to do in software security. To know how much work, think about software security as a metaphor of car safety. In automobile industry metaphorical terms, the state of the art of countermeasures built in today's software are like air bags that inflate after a car crash accident had occurred.  Consider for example that it takes months on the average for a company to detect a data breach incident (based upon Verizon data breach reports) since the time the security accident had occurred.  Most of data breaches today are detected after the data has been lost, similarly to air bags that detect car crashes and explode after the passengers are either already dead or injured. Unfortunately, there is no air bag equivalent security measure in software today and there is not car crash test equivalent to test security measures.

Car Air Bag
(Source http://www.airbagecu.com/)

Also consider the inherent risks due to the high value of the data assets and the critical business functions that software stores and process today such as software that runs critical industrial systems like SCADA and runs oil, gas, water and electric utilities, that control manufacturing, traffic controls and mission critical systems for the military. In the financial industry, this is the critical software that handles payments,allows to trade stocks and bonds seldom for million of dollars per transaction. A little bit closer to our every day experience as consumers, consider software for online purchases and that processes and stores credit cards data. Software that is critical for business functions and for the operation of critical business services is today under the focus of persistent attackers and need adequate countermeasures. Let me try to use the car analogy for highly sought targets from attackers. This would be like the limousine car carrying the president of the United States for a state visit trip. Because of the threats that the presidential car might face, it would need at least high grade security built into the car like bullet proof glass and doors. Other cars with secret service agents would escort the presidential car as well to provide a layered defense. The presidential car is not built with the protection of an average car and is not given average security protection. This is because the president is an highly value asset and needs extra level of protection. Similarly, business critical software is an high value asset that needs a level of security that is higher than commercial off the shelf software. For example, business critical software need at minimum additional layers of preventive and detective security. Yet business critical software today is engineered by following more or less the same design of countermeasures of average software that is 20 years behind today car safety standard technology such as air bags. So I hope you got my point with the car metaphor. Today's software security is not adequate because is not resilient enough to cope with the new threat landscape. Today software applications that protect critical company and government digital assets are under the siege of motivated threat agents and persistent attacks. In today threat landscape, business critical software would need the equivalent security of a tank or a bullet proof car.  So how we can catch up with the threats ? We need to work toward more resilient and attack proof software.  We need to design and implement countermeasures that make more costly for attackers to bypass. We need  preventive and detective controls to evolve to effectively detect fraud and prevent fraud and identity theft. We need to move on from infrastructure and perimeter security as network firewalls and intrusion detection systems were good security measures to protect from the cyber attacks of the late 90s and not adequate to protect from today's threats. Because of this, today's cybercrime is an industry that strives with profits of several millions of dollars for cyber criminals by selling malware that is designed to hack into the consumers bank accounts and steal credit card data.  Today cybercrime tool vendors offer a money back guarantee to a fraudster in case a cybercrime tools won't provide the financial gain that was sought (e.g. stealing money from bank accounts). Yes, in the mean time we worked to build more secure software, the cybercrime industry did not waste time and our effort of securing software today is not catching up with the threats we face. Not to underscore the progress we made in software security, if you read the the 2006 DHS Security in the SDLC (S-SDLC) guidelines, we can say that after 6 years, most of software organizations conduct penetration tests and some even have deployed static source code analysis tools that automate the process to identify vulnerabilities in source code. This means there are fewer number of vulnerabilities available to exploit by the attackers. We also have software security maturity models like BSIMM that help software development organizations to compare their software security practices among peers and focus their security efforts in the security domains and activities that need the most effort. This is all good but not enough because the threat landscape has changed and the exposure of software to cyber threats has increased dramatically. Consider the widespread use of software for mobile applications and the millions of people storing personal data on social networking sites. Consider the corporate data stored and processed by software in the cloud and the software that processes and stores personal identifiable information such as voice fingerprints for authentication and user's images for a person identification. Today, there is a disconnect between the escalation of cyber threats, the increased exposure of software to cyber threats and the effectiveness of the countermeasures for protecting and detecting cyber threats. Today software security need to evolve and bake in new countermeasures that need to work like a car air bag. Since Microsoft released a threat modeling methodology ten years ago, we had a software centric based approach to design secure software that considered threats against software components including data assets. This methodology is based on a simplified view of threats such as STRIDE (Spoofing Tampering Repudiation, Information Disclosure, Denial of Service and Elevation of Privileges). This type of threat modeling today is not adequate for designing secure software because threats and attacks have evolved from the basic threats. Consider the example of an attacker using an interface that takes credit card information not to steal credit card data but to enumerate which credit card numbers are valid so can be used for online purchases or counterfeit credit cards. This is a type of threat that STRIDE does not categorizes because is tied to business impact not technical impact. Today attacks against application's software not only seek to compromise the data assets but also to abuse the critical application functionality.  In a today threat model, the analysis of use and abuse cases and of business impacts caused by vulnerability exploits are essential to identify countermeasures and mitigating business risks. The attack surface of today's applications has also become wider including all the available application interfaces and channels that are exposed to a potential attacker. In enterprise wide software and applications the targets are not just one software component or library but the whole services provided to customers and partners. An attacker will seek to compromise different channels that lead to the data assets such as online, mobile and B2B channels and in the cloud where data is either stored or processed.

Tony UV Gives a talk on P.A.S.T.A. Threat Modeling
ATL BSides Conference in Atlanta, 2011

A comprehensive threat model today need to analyze the abuse of software and application functionality by an attacker to determine the possible business impacts. Today's software need to be tested with the equivalent of car crash tests to probe the security measures in place assuming that a compromise of one measure won't result on a catastrophic loss of the assets such as data and critical business functions. As I saw the need of a new way to look at threats, vulnerabilities and attacks, I embarked with my friend Tony Ucedavelez CEO of Versprite in a passionate effort to develop a new process for the analysis of cyber threats by focusing on business impacts and with the ultimate objective of protecting the company digital assets such as data and critical business functions. This is not a stand alone threat model for software developers but a risk framework that can be used by organizations to analyze the impacts to the assets and critical business functions assuming these can be attacked and compromised. This means to consider the attack as a mean to the attacker goals. The foundation of this application threat modeling methodology is a new risk framework and process. This threat modeling process consists on the "Process for Attack Simulation and Threat Analysis" (P.A.S.T.A). Pasta is a food metaphor for threat and attacks and it is used to educate security people to threat and attack analysis. Using the food metaphor, pasta is taught as the basic ingredient for cooking quality meals as threat modeling is the basic ingredient to build secure applications. Since an attack describes how a threat is realized, this methodology outlines the steps for analyzing threats and attacks and build countermeasures as a recipe for cooking good pasta.  The modeling threats and attacks, threat modeling drives the design of protective and detective measures to minimize business impacts. For example, the correlation of attacks to possible exploits of vulnerabilities can be used to design preventive and detective measures. Since we need tools to conduct this process and the correlation between threats, attacks and vulnerabilities, we convinced the company, myAppSecurity Inc to develop the threat modeling tool to support this process. The tool threatModeler (TM)  helps software developers in conducting the steps of the methodology and produce threat models of the applications. In the mean time, Tony UV and I started giving talks about threat modeling by attending several security conferences (e.g. Universities, OWASP, BSides). We spent the last three years learning what works and what does not work. Education of software engineers and software security professionals in threat modeling is key for success. Also in most of software development organizations today, threat modeling is misunderstood as software security methodology. For this reason, it is either missing as S-SDLC activity or it is considered  as complimentary of other consulting security engagements such as pen testing and secure code reviews. Instead threat modeling is central to the application security risk mitigation strategy since allows to map threats to attacks and attacks to vulnerabilities and to highlight the exposure to threats of the data and critical business functions. Threat modeling allows the business to understand the risks of the exposure of data assets by vulnerabilities and the determine the effectiveness of security measures in place. Threat modeling allows to perform a defense in depth analysis by determining how defenses can be bypassed by an attacker and identify where layered controls need to be implemented. Threat modeling allows to model the abuse cases of critical business functions so these can be used to crash test security measures and to determine how effective these are for protecting and detecting from the attacks. Ultimately, application threat modeling allow the business to decide which security measures are the most effective in mitigating risks of attacks and implement the security measures that minimize the risks and minimize the costs of implementing them. While security, engineering and business teams work together and follow the steps of P.A.S.T.A., they learn how to develop resilient software and translate software security into business value so that the business can make informed risk decisions. Finally, on the topic of application threat modeling, we have a book coming up where we collected our ideas and experiences in eight monumental chapters. The intent is to help others with our experience in the field and to educate the new generation of security professionals on how to design and implement resilient and attack proof application software for today's and future cyber threats.  So be prepared soon to reboot your security program as well and start a new journey leading to a destination where software and applications are resilient and attack proof like a cars are safe in accidents because are designed to use air bags and probed with crash tests.