Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

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
 

Recommended Reading:

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 !
Edge-DRsplash-10-edge-articles
7 Old IT Things Every New InfoSec Pro Should Know
Joan Goodchild, Staff Editor,  4/20/2021
News
Cloud-Native Businesses Struggle With Security
Robert Lemos, Contributing Writer,  5/6/2021
Commentary
Defending Against Web Scraping Attacks
Rob Simon, Principal Security Consultant at TrustedSec,  5/7/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: Take me to your BISO 
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
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-2021-20538
PUBLISHED: 2021-05-10
IBM Cloud Pak for Security (CP4S) 1.5.0.0 and 1.5.0.1 could allow a user to obtain sensitive information or perform actions they should not have access to due to incorrect authorization mechanisms. IBM X-Force ID: 198919.
CVE-2021-20559
PUBLISHED: 2021-05-10
IBM Control Desk 7.6.1.2 and 7.6.1.3 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 199228.
CVE-2021-20577
PUBLISHED: 2021-05-10
IBM Cloud Pak for Security (CP4S) 1.5.0.0 and 1.5.0.1 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force I...
CVE-2021-29501
PUBLISHED: 2021-05-10
Ticketer is a command based ticket system cog (plugin) for the red discord bot. A vulnerability allowing discord users to expose sensitive information has been found in the Ticketer cog. Please upgrade to version 1.0.1 as soon as possible. As a workaround users may unload the ticketer cog to disable...
CVE-2020-13529
PUBLISHED: 2021-05-10
An exploitable denial-of-service vulnerability exists in Systemd 245. A specially crafted DHCP FORCERENEW packet can cause a server running the DHCP client to be vulnerable to a DHCP ACK spoofing attack. An attacker can forge a pair of FORCERENEW and DCHP ACK packets to reconfigure the server.