Reviews of design diagrams by domain experts can detect potential security breaches not found by vulnerability scans or security automation. Such reviews should focus on critical functions like issuing and managing access tokens, transferring data to external services, and running untrusted code, said Kevin Gilpin, enterprise software engineer and co-founder of AppLand, at QCon London 2019.
We are used to seeing security breaches caused by technical flaws such as unsafe memory access and OWASP vulnerabilities. But lately, there have been important breaches which were actually caused by fundamental design flaws in the application software. These breaches would not have been detected by vulnerability scans or by other forms of security automation, said Gilpin. He gave the example of Facebook who recently had to reset the security access tokens of 50 million users after one of their new features, View As, was found to have a fundamental security vulnerability that was leaking access tokens to unauthorized users.
Security flaws in application design can have a huge impact, argued Gilpin. There is frequently no way to mitigate these flaws without going back to the drawing board, re-designing, and re-writing the software completely. Many regulated and compliance-certified (e.g. ISO, HIPAA) organizations have a multi-step design review, which can help to find security flaws. The trick is adapting this process to fast-flow development, he said.
The first step is to identify the projects or components where the most risk lies. These are the areas which perform the most critical functions. Gilpin mentioned examples like issuing and managing access tokens, transferring data to external services, and running untrusted code. These are all functional areas which, if improperly designed, can lead to critical breaches.
Once these high-risk areas of the code are identified, then a set of accurate design diagrams is prepared by engineering. Ideally, diagrams are generated directly from code using automation tools, said Gilpin. If necessary, these can be supplemented with manually drawn diagrams, although it’s harder to keep these up-to-date with the ever-changing code-base. Once prepared, design diagrams are distributed along with some explanatory text for review by domain experts, such as security. Gilpin suggested that each reviewer will focus on verifying the design from a specific point of view. Most importantly, a reviewer will identify when an existing, well-known design such as an RFC could be used in place of a custom, in-house design.
The security reviewer should be familiar with the best practices and state-of-the-art with regard to authentication, authorization, OWASP, and safely handling untrusted code and untrusted user input, said Gilpin. If there is no such expertise within the organization, then it’s a good idea to widen the search and perhaps engage an external expert to perform the review. That can be money well spent, when compared to the monetary and reputation damage that a breach can do.
InfoQ is covering QCon London 2019 and spoke with Kevin Gilpin on the role of architecture and design artifacts when it comes to security.
InfoQ: What are the properties of good cognitive architecture or design artifacts?
Kevin Gilpin: A good cognitive artifact, such as an architecture diagram or software design diagram, must be something that can help focus the attention of the people who need to weigh in. If those people are outside of development, it must be easy for non-coders to understand as well. Yet, a good cognitive artifact must also represent the actual design and behavior of the software well enough that it provides an accurate view of how the software works.
So it is a bit of a Goldilocks problem dependent on your audience. If it has too many details of the code, then non-programmers can’t understand it. And if it’s too high-level to represent the complexities of the design, then it won’t be useful as a way to get feedback and suggestions.
InfoQ: What can be done to ensure that architecture and design artifacts will be up-to-date?
Gilpin: This is a difficult problem. Historically, there have been efforts such as CASE (computer aided software engineering) which tried to put design diagrams at the center of the software engineering process. However, in today’s world the code is king. The code is at the center of critical processes such as code reviews, pull/merge requests, automated testing, continuous integration, and automated deployment. So, design artifacts only stay up-to-date if there’s effort made to keep them up-to-date with the ever-changing code. That’s why design artifacts are normally out-of-date and therefore they aren’t really at the center of any important processes in software development today. There are some automated tools which can help to provide design insights directly from the code, but they are limited. This is an area in which we need innovation in techniques, practices and tooling.
InfoQ: What can be done to accommodate the needs of both technical and non-technical stakeholders when discussing security?
Gilpin: To catch flaws like the Facebook View As breach, it’s important that a wider circle of people be able to understand and think about the design of software applications. Software developers have a lot of responsibilities; designing, coding, testing, continuous integration, DevOps, estimation, performance, bug fixing, learning new tech, communicating with each other, etc. Sometimes, security concerns can fall behind. Security teams on the other hand, can focus on security. So, if developers can make their designs accessible to security, and if developers and security teams can work together in a productive way within the organization, then when they work together it can be a powerful new tool for improving application security.
