Application Security

6/19/2015
10:45 AM
Patrick Thomas
Patrick Thomas
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

9 Questions For A Healthy Application Security Program

Teams often struggle with building secure software because fundamental supporting practices aren't in place. But those practices don't require magic, just commitment.

One of the mementos that I've carried on my migration from software development to information security is a piece written by Joel Spolsky, of Stack Overflow fame. Called the "Joel Test," it's a quick, back-of-the-envelope indicator for whether a development team is set up for success or failure. Pointedly succinct but uncompromising, it helps cut through bureaucratic hedging, and it's always in the back of my mind when I'm working with development teams.

However, I've noticed that it's difficult for many developers—and management—to achieve this intuitive level of clarity about having the proper pieces in place to build software securely. Security is a special sort of requirement and can't be treated like just another nonfunctional requirement; the design and testing approaches are very different. To help organizations and teams discuss whether they are prepared to build secure software, I've taken inspiration from the original Joel Test to pose nine key questions about application security.

1. Do you have an application inventory?
Any organization developing or deploying multiple applications needs a single point of reference for metadata about applications. Questions such as "who are the points of contact?" "what does it interact with?" "where is it deployed?" "how sensitive are the systems and data?" "what are the dependencies?" and dozens of others are going to be of interest to groups in the organization outside the immediate development team. Tracking down individual developers is not a practical solution.

2. Can you deploy environments in one step?
Security testing is messy. In the best cases, it only fills up logs and eats bandwidth, but in the worst cases (and where it's needed most), it has a tendency to regularly make entire environments unusable for any other purpose. Organizations able to create complete environments easily are far better prepared to perform adequate testing, not just security testing.

An additional outshoot of this level of automation is that it reduces vulnerabilities stemming from misconfigurations and deployment issues.

3. Do you do threat modeling?
Security thinking is a different type of thinking. Threat modeling is a powerful tool for making sure that security concerns get a seat at the table during architectural and early feature discussions. Later on, when smaller details are being worked out, the actual threat model document helps make those concerns concrete.

4. Do you have a Secure Development Lifecycle?
It's easy to make the SDL a catch-all for security practices or get bogged down in the tremendous amount of content out there about implementing one. The overarching point, however, is that security considerations and practices get fully considered in every step of the process and intentionally integrated into the day-to-day work of creating software. A team diligently executing an SDL is going to tick a lot of boxes on this list.

5. Is secure development part of developer training?
Breaking systems requires a different mindset than building them. There's nothing that says an individual can't do both, it's just that they're different skills, and practicing the latter doesn't necessarily hone the former. Even when writing my own code, I will walk away from a project for a day or so to make sure that I've sufficiently purged any preconceptions about how the code "should" work. Effective developer training not only equips developers with prescriptive "do's" and "don'ts," but provides examples of attacks and attacker tools to help them don the appropriate mindset.

6. Do you choose technologies and approaches that eliminate entire classes of vulnerabilities?
In my experience, this is one of the most powerful determiners of whether an application is "mostly secure" or "mostly insecure." Smart pointers, ASLR/DEP, managed languages, prepared statements, the controller pattern, and Content Security Policy are all excellent examples. The ability to systemically remove entire areas of concern at the design phase can have huge impacts during implementation, testing, and maintenance. Any details that can be offloaded from a developer's mind onto a useful and secure-by-default technology stack are potential bugs that never get written.

7. Do you use automated scanning and testing tools?
Security testing often requires testing exponential combinations of payloads and contexts, far too many to be part of manually developed testing suites. Automation is the only tractable approach, and sophisticated tools exist for both static and dynamic analysis of software for a huge range of issues. Attackers automate mercilessly to find vulnerabilities and exploit them at scale. Defenders that fail to automate will find that important processes won't be done often or well.

8. Do you conduct penetration tests?
Security tools and automation can uncover a wide range of technical flaws; I'm often amazed at the obscurity of conditions and paths they discover. However, tools don't tend to be good at providing a realistic adversary simulation. Goal-based penetration testing is useful to find logic flaws and chains of lower-severity issues that can result in significant compromise. Penetration tests also give an attacker's view of the application; a legacy PHP site or broken "forgot my password" functionality can easily negate excellent security practices on an otherwise shiny new application.

9. Does software security have an advocate at the executive level?
All engineering requires balancing competing concerns, and security is another one jockeying for resources. A security initiative unable to allocate and defend resources (money, people, time) is destined to be marginalized.

As with the original Joel Test, an organization might be able to get by with missing one or two of these questions. However, a mature organization is going to nail every single one as a matter of course. The common theme here is that "secure development" really needs to be thought of as simply "development." Creating artificial distinctions between the two moves resources and expertise away from the places it can do the most good. Conversely, frontloading security as requirements and using tools and training to keep security considerations close to mind can eliminate issues sooner and cheaper.

Patrick Thomas is a recovering software developer turned Senior Security Consultant with the Cisco Security Solutions group. As a penetration tester, he helps organizations understand attackers' views of their systems, and as a consultant he helps teams build practices and ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Kevin Runners
50%
50%
Kevin Runners,
User Rank: Apprentice
6/25/2015 | 8:39:06 AM
Point 6 is the most important
The 6th point is the most important in my opinion. Technologies and approaches must eliminate entire classes of vulnerabilities. How could it be different ?
Crowdsourced vs. Traditional Pen Testing
Alex Haynes, Chief Information Security Officer, CDL,  3/19/2019
New Mirai Version Targets Business IoT Devices
Dark Reading Staff 3/19/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Reading Schneier's Friday Squid Blog again?
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-6149
PUBLISHED: 2019-03-18
An unquoted search path vulnerability was identified in Lenovo Dynamic Power Reduction Utility prior to version 2.2.2.0 that could allow a malicious user with local access to execute code with administrative privileges.
CVE-2018-15509
PUBLISHED: 2019-03-18
Five9 Agent Desktop Plus 10.0.70 has Incorrect Access Control (issue 2 of 2).
CVE-2018-20806
PUBLISHED: 2019-03-17
Phamm (aka PHP LDAP Virtual Hosting Manager) 0.6.8 allows XSS via the login page (the /public/main.php action parameter).
CVE-2019-5616
PUBLISHED: 2019-03-15
CircuitWerkes Sicon-8, a hardware device used for managing electrical devices, ships with a web-based front-end controller and implements an authentication mechanism in JavaScript that is run in the context of a user's web browser.
CVE-2018-17882
PUBLISHED: 2019-03-15
An Integer overflow vulnerability exists in the batchTransfer function of a smart contract implementation for CryptoBotsBattle (CBTB), an Ethereum token. This vulnerability could be used by an attacker to create an arbitrary amount of tokens for any user.