Technology powerhouses such as Google, Microsoft, and Apple know how to get security right. They invest in the best technology, processes, and people to ensure that their engineering teams create secure software.
They're open about their methods for product security engineering. For example, Michal Zalewski, previously head of product security at Google and now VP of security at Snap, has a fascinating blog post with thoughts on how to manage a product security team. The Microsoft Security Response Center has a blog where team members regularly share ideas on how to improve security.
What sets apart the largest and most innovative software engineering organizations? Here are five approaches for changing your security practices and improving your security mindset and posture. These don't require investments akin to those made by technology giants.
Safer APIs to Prevent Vulnerabilities
Prevention is better than a cure, and ideally you make certain common mistakes impossible. For instance, common cross-site scripting vulnerabilities can be avoided by judicious use of automatic context-aware escaping. Similarly, the notorious problem of SQL injection can be avoided if you give up the ability to run arbitrary string data as queries on a database; instead, you should use a restricted API that builds up the queries in a structured manner — for instance, as prepared statements.
Catch Vulnerabilities at Time Zero
Mistakes will happen, even with perfectly designed, safe APIs. It's important, therefore, to continuously run analyses that catch mistakes that slipped through. The perfect point to do that is at code review time: close enough to time zero so that the developer's focus is still with the relevant code change, and yet with a time budget to run deep analysis. This article by the Google code analysis team explains the prerequisites for success. As the team points out, it's critical that the creation of new analyses can be crowdsourced, with everyone chipping in to define what good, secure coding standards are, and updating the analyses when new classes of vulnerabilities are identified.
Red Teams and Pen Testers to Identify New Blind Spots
To identify your blind spots, use internal red teams to do penetration testing or hire an outside company to attack your systems. It's an investment, but it can catch problems that are hard to detect mechanically. Bug bounty programs, such as those administered by BugCrowd and HackerOne, can be effective to find your blind spots. However, it's a waste of money if you don't implement the cheaper, automated means to first fill the more obvious holes. In fact, advances in artificial intelligence make it possible to apply some of the fuzzing techniques that professional pen testers employ, but automatically — the Microsoft Security Risk Detection service is an example. When pen testers or automated fuzzers find new blind spots, eliminate them by creating new code analyses, as described in the previous paragraph.
Make It Very Hard to Exploit Vulnerabilities
You're not going to stop all vulnerabilities entering the source code, so you must be prepared for the worst, making sure that even while vulnerabilities are there, they're extremely hard to exploit. One area under heavy development is that of moving target defense: randomizing heap layout (or code layout) so that attackers have a hard time figuring out how to exploit weaknesses in the code. Address space layout randomization, known as ASLR, is used as additional protection in Windows and Android, for example.
Organizational Structure: The Product Security Team
So far, we've looked at technical remedies, but organizational structure is important too, as argued in the blog post by Michal Zalewski mentioned earlier. A common theme at the best software companies is that there is no strict separation between security and engineering: The two are working together, always looking for opportunities to automate security expertise and integrate it into the developer workflow. For example, in the recent news that Facebook's security chief Alex Stamos resigned, The New York Times quoted an internal memo stating that the security team would no longer operate as a stand-alone entity but instead work more closely with product and engineering teams.
This trend has a name: the product security team. Typically, this team lives in the engineering organization, with a dotted line to the CISO, if that function exists. The CISO looks after IT security much more generally, while the product security team takes responsibility just for the products being developed internally.
The consequences of not moving product security into engineering can be very bad: Security teams simply report on problems and the dev team is pushed to deliver on new features instead of security and ignores the reports by the security team. Security teams are given incentive to report as many problems as possible (covering their butts in case of a breach), yet developers don't have time to look at all these reports because many of them are not real bugs but false positives. This separation is the old way, and it has been discredited.
True product security can only be achieved when all developers take responsibility for the security of the code that they write. The product security team's job is to give developers the knowledge and tools to do just that.
There is no standard playbook for how these important tech companies handle security, but they are sharing their tried-and-true methods with the community — something every company successful at security should do. As an industry, we need to think of security as an ecosystem, and sharing best practices is the best way to individually and collectively improve.
What sets apart the largest and most innovative software engineering organizations? These five approaches are a good way to start, and they won't break the bank.
Black Hat Europe returns to London Dec. 3-6, 2018, with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions, and service providers in the Business Hall. Click for information on the conference and to register.Oege de Moor is the CEO and Co-Founder of Semmle. Prior to founding Semmle, he spent 21 years as a Professor of Computer Science at Oxford. During a sabbatical from Oxford, he joined Microsoft as a Visiting Researcher, working with Charles Simonyi (the original creator of ... View Full Bio