Information security and software architecture in the digital age
The quest for digital transformation has guided business strategies today, and in this context, several pillars of IT stand out, among them: software development (look around and ask yourself: how far do you is a software application?), and information security, whose value lies in risk reduction (one of the principles of IT governance).
Considering the speed with which practices are changing, the development and use of software can often seem more of an art than a science. As software tools and methodologies become increasingly available, there is a greater opportunity to develop software, but also to defraud existing systems. In addition, the software is now widely shared and new approaches to reduce the cost of development, minimize the risks of information security and increase the speed of delivery are constantly growing and expanding. As organizations rely on evolving technologies, patterns of operational failure, misuse, and abuse emerge more often from a variety of sources as well as weak internal practices during software acquisition or development.
Safe (in) development?
The difference between safe and unsafe software is subtle, where most of the time we listen to suppliers that their systems are "safe". Almost all software-controlled systems face threats, software engineers must be aware of these threats and design systems with reliable defenses while delivering value to customers. Recently the Open Web Application Security Project (OWASP) has published an indispensable list of Top 10 2017/2018 Top 10 application security risks.
Integration is the key word!
Currently there is a high range of software architecture types, as well as security practices that have become increasingly popular, such as DevSecOps. The big problem is that most integrations between the software architecture process and security reach the most succinct layers (almost a standard). We can not just follow standards to follow, it is necessary to generate added value and with this opportunity that digital transformation allows us to start a new phase in security with the concept of threat modeling.
Threat Modeling methods should be used to create an abstraction of the system; profiles of possible attackers, including their goals and modus operandi, plus a catalog of potential threats that may arise. There are already some threat modeling methods developed, but not all are comprehensive; some focus on abstraction and encourage granularity, while others are more person-centered. It is also possible to combine such methods and, from this, to create robust and comprehensive visions by working directly with the software architecture, ie, mitigating the cycle of a risk (vulnerability> threat> risk> business impact ).
Here are some threat-modeling methods that should be incorporated into the software architecture as an indispensable requirement:
• STRIDE is a more mature method of threat modeling, where design is evaluated in detail of the system;
• LINDDUN (Linkability, Identifiability, Non-Repudiation, Disclosure of Information, Unawareness, Non-Compliance) is a method of threat modeling that focuses on privacy issues and can be used for data security. Similar to STRIDE, Liddun, consists of coding threat categories and provides a systematic approach to privacy assessment;
• CVSS (The Common Vulnerability Scoring System) is a method that captures and identifies the main characteristics of a vulnerability and generates a numerical score that reflects its severity;
• OCTAVE (The Operational Critical Threat, Asset, and Vulnerability Evaluation) is a risk-based strategic planning and evaluation method for cyber security. OCTAVE focuses on the assessment of organizational risks and does not address technological risks. Its main aspects are operational risk, safety practices and technology.
Threat modeling not only adds value to the enterprise product, but also provides a holistic security view of the system components. In this short article we present different methods of threat modeling. Some of them can be used alone or together, but all must be tied to the chosen software architecture.