Vulnerabilities / Threats //

Advanced Threats

11/8/2018
10:30 AM
Oege de Moor
Oege de Moor
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

5 Things the Most Secure Software Companies Do (and How You Can Be Like Them)

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.

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.

Related Content:

 

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
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Cheeseman
50%
50%
Cheeseman,
User Rank: Apprentice
11/12/2018 | 9:49:14 AM
Home run article
You in effect nail it by highlighting companies that are the most successful at securing their code. Instead of layering on controls and legislation companies can reduce vulnerability exposure by doing a great job in the development process. Thank you !
Microsoft President: Governments Must Cooperate on Cybersecurity
Kelly Sheridan, Staff Editor, Dark Reading,  11/8/2018
5 Reasons Why Threat Intelligence Doesn't Work
Jonathan Zhang, CEO/Founder of WhoisXML API and TIP,  11/7/2018
Why Password Management and Security Strategies Fall Short
Steve Zurier, Freelance Writer,  11/7/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Flash Poll
The State of Ransomware
The State of Ransomware
Ransomware has become one of the most prevalent new cybersecurity threats faced by today's enterprises. This new report from Dark Reading includes feedback from IT and IT security professionals about their organization's ransomware experiences, defense plans, and malware challenges. Find out what they had to say!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-6260
PUBLISHED: 2018-11-13
NVIDIA graphics driver contains a vulnerability that may allow access to application data processed on the GPU through a side channel exposed by the GPU performance counters. Local user access is required. This is not a network or remote attack vector.
CVE-2018-16850
PUBLISHED: 2018-11-13
postgresql before versions 11.1, 10.6 is vulnerable to a to SQL injection in pg_upgrade and pg_dump via CREATE TRIGGER ... REFERENCING. Using a purpose-crafted trigger definition, an attacker can cause arbitrary SQL statements to run, with superuser privileges.
CVE-2018-17187
PUBLISHED: 2018-11-13
The Apache Qpid Proton-J transport includes an optional wrapper layer to perform TLS, enabled by use of the 'transport.ssl(...)' methods. Unless a verification mode was explicitly configured, client and server modes previously defaulted as documented to not verifying a peer certificate, with options...
CVE-2018-1792
PUBLISHED: 2018-11-13
IBM WebSphere MQ 8.0.0.0 through 8.0.0.10, 9.0.0.0 through 9.0.0.5, 9.0.1 through 9.0.5, and 9.1.0.0 could allow a local user to inject code that could be executed with root privileges. IBM X-Force ID: 148947.
CVE-2018-1808
PUBLISHED: 2018-11-13
IBM WebSphere Commerce 9.0.0.0 through 9.0.0.6 could allow some server-side code injection due to inadequate input control. IBM X-Force ID: 149828.