You can easily measure your security testing effectiveness by adding up the millions of dollars that businesses have lost. A 2017 study about the cost of data breaches by the Ponemon Institute found that organizations have a one in four chance of experiencing a material data breach in the next two years.
You might be tempted to treat security the same way you treat any other quality control. Tests are incorporated in the same places where functional, integration, performance, or other kinds of software testing are implemented. But delivering trustworthy pass/fail results is far more straightforward when dealing with functional requirements such as the behavior of a given button on a screen.
Security testing is rarely that conclusive. Here's what your team needs to know about how security testing differs from other types of software testing.
Nebulous is the norm
Functional requirements focus on a finite set of expected good things. In contrast, security requirements focus on protecting against an infinite set of constantly shifting, difficult-to-predict, bad things.
That's tough to automate, but not impossible.
You can incorporate automated tests into your the continuous integration/continuous delivery (CI/CD) pipeline to quickly and accurately spot regressions. To get value from your security testing investment, you need to shift how you think with regard to the results produced by these tests And you need to be willing to follow through with manual controls, such as code reviews.
Even automation against requirements can provide a mix of concrete results and less conclusive, but still useful, evidence to help humans answer whether or not a requirement has been met.
For example: Are encrypted communications being validated to prevent man-in-the-middle attacks? That is a big question that must be broken down. Some specific pieces—such as checking for expired certificates, the use of fully qualified domain names, and creating a valid chain of trust down to the issuer—can be automated. Qualys's free SSL Server Tests check these items and more, and offer APIs that can be incorporated into your test suites.
Other pieces, such as how your application handles these certificates, require an experienced human who knows the application well.
Forget the firewall
Hosting on dedicated hardware or on a private cloud behind a firewall inside your organization provides a measure of protection, albeit a very small one. Yes, firewalls, which block malicious traffic, are your first line of defense against outside attackers. But focusing externally leaves your organization vulnerable to the biggest threat: insiders.
Only 8% of professionals in a Ponemon study of data protection cited external attacks as the primary cause of data breaches they had experienced. But 78% cited negligent or malicious employees and contractors. Insider incidents were also the costliest to fix.
Shifting hosting to the cloud also means a shared responsibility for security between the cloud provider and you. Cloud services such as AWS, Azure, and Google are responsible for protecting the infrastructure and providing services for you to configure. You are responsible for configuring everything securely— something few developers know how to do.
Testing once isn't enough
By default, Amazon Simple Storage Service (S3) buckets are locked down to allow access only by the account owner. But protections offered by that configuration can be wiped out with a click of the mouse by an otherwise well-meaning developer. S3 misconfiguration problems are so widespread that Amazon has provided a free check of public permissions for customers.
Continuous testing of cloud security configurations is needed to spot these problems early and often. Better yet, treat infrastructure as code and test that code as you would application code before every deployment. You'll finally realize the cost-saving promise of the cloud by ensuring that only what is needed is running. Forgotten hosts left running are a tempting attack surface for bad actors.
The journey starts with a single step
Daunting cloud service provider dashboards, along with endless stories of expensive, public breaches, might make the task of securing your software seem overwhelming. But, as with any testing effort, security is a journey that begins when you write your first test. Next steps should be decided based on the risk they address.
Should you ensure that your application logs all change to the logging configurations? Absolutely. When a security incident occurs, this level of detail is invaluable to investigators trying to pinpoint problems and help quickly stop the bleeding.
But if you are not yet testing for more common and easily exploited vulnerabilities, such as injection of SQL or OS commands, robust logging is only going to demonstrate how vulnerable your application is. Resources such as OWASP’s Top 10 list of application security risks can guide you in making the best next step in your journey.
Vendor-supplied test tools can fill gaps in security testing and your team's security experience, but they aren't magic. Dynamic application security testing can uncover vulnerabilities visible only at runtime, and is very good at finding the OWASP Top 10.
Static code checkers are good at finding serious vulnerabilities, such as credentials embedded in the source code, but these produce many false positives. Experienced professionals still must review test results before handing code off to developers for fixes.
Take it to the next level
Developers are often asked to wear a security testing hat as well, and they should. Successful quality control begins at the unit test level, right on the developer's laptop, where bugs are the easiest to spot and the least expensive to fix. Developers are already in a defensive programming mindset as they create unit tests, thinking of abuse cases alongside use cases. Take that to the next level by thinking evil.
Techniques such as threat modeling force you to think like a bad guy, breaking down an application into its components, looking at where data flows between them, and seeking out the weak spots. GUI testers make great security testers because they spend much of their time thinking not just about how something should be used, but all the ways it can and will be misused as well.
If you aren't sure where to start, cloud users can look to the Center for Internet Security's benchmarks for Microsoft Azure and Amazon Web Services for help. AWS also has recipes for ensuring compliance with policies such as the Health Insurance Portability and Accountability Act (HIPAA) and the Federal Risk and Authorization Management Program (FedRAMP).
What has your team learned? Share your security testing best practices below.
Keep learning
The future is security as code. Find out how DevSecOps gets you there with TechBeacon's Guide. Plus: See the SANS DevSecOps survey report for key insights for practitioners.
Get up to speed fast on the state of app sec testing with TechBeacon's Guide. Plus: Get Gartner's 2021 Magic Quadrant for AST.
Get a handle on the app sec tools landscape with TechBeacon's Guide to Application Security Tools 2021.
Download the free The Forrester Wave for Static Application Security Testing. Plus: Learn how a SAST-DAST combo can boost your security in this Webinar.
Understand the five reasons why API security needs access management.
Learn how to build an app sec strategy for the next decade, and spend a day in the life of an application security developer.
Build a modern app sec foundation with TechBeacon's Guide.
