SlideShare a Scribd company logo
T17
Security Testing
5/2/2013 1:30:00 PM

Better Security Testing: Using the
Cloud and Continuous Delivery
Presented by:
Gene Gotimer
Coveros, Inc.

Brought to you by:

340 Corporate Way, Suite 300, Orange Park, FL 32073
888-268-8770 ∙ 904-278-0524 ∙ sqeinfo@sqe.com ∙ www.sqe.com
Gene Gotimer
Gene Gotimer is a senior architect at Coveros, Inc., a consulting company that uses agile methods to
accelerate the delivery of secure, reliable software. Gene is an experienced software developer who
focuses on continuous integration, static code analysis, automation, and any tool he can find to do his
work for him. For the past few years, he has been on a team that is bringing a continuous delivery process
into the US Department of Defense, showing that higher quality software can be delivered quicker and
with more security by using agile techniques.
4/16/2013

Gene Gotimer, Senior Architect
gene.gotimer@coveros.com

© Copyright 2013 Coveros, Inc. All rights reserved.

1

About Coveros

Coveros helps organizations accelerate the delivery of
business value through secure, reliable software

© Copyright 2013 Coveros, Inc. All rights reserved.

2

1
4/16/2013

Security Testing
Late in the cycle
Issues are not remediated
Needs ROI: lower cost, better results, or both

© Copyright 2013 Coveros, Inc. All rights reserved.

3

Security Testing
Consider open-source and free tools
Opportunities in Continuous Delivery and Cloud

Identify low effort opportunities using free
and open-source tools

© Copyright 2013 Coveros, Inc. All rights reserved.

4

2
4/16/2013

Continuous Integration
Merge work frequently
Code commits to source control
Unit tests run automatically
No long integration cycle at the end
Fix code when we find problems
Build-Test-Commit cycle = rapid feedback

© Copyright 2013 Coveros, Inc. All rights reserved.

5

Continuous Delivery
Every build potentially releasable
Release is a business decision
Extrapolation of Continuous Integration
– Deploys
– Functional tests
– Load and performance tests
– Security tests
Build-Test-Commit-Deploy-Test-Release cycle

© Copyright 2013 Coveros, Inc. All rights reserved.

6

3
4/16/2013

Cloud Computing
Can’t wait for long procurement
Public or Private clouds
Works well with Continuous Delivery
– Easy to deploy
– New environments whenever

© Copyright 2013 Coveros, Inc. All rights reserved.

7

Maturity Model for Security Testing
Level 0: No Security Testing
Level 1: Unit Testing and Static Analysis
Level 2: Automated Deploys and Functional Testing
Level 3: Automated Configuration Management
Level 4: Cloud Deployments
Level 5: Continuous Delivery

© Copyright 2013 Coveros, Inc. All rights reserved.

8

4
4/16/2013

Maturity Model for Security Testing
Level 0: No Security Testing
Level 1: Unit Testing and Static Analysis
Level 2: Automated Deploys and Functional Testing
Level 3: Automated Configuration Management
Level 4: Cloud Deployments
Level 5: Continuous Delivery

© Copyright 2013 Coveros, Inc. All rights reserved.

9

Maturity Model for Security Testing
Level 0: No Security Testing
Level 1: Unit Testing and Static Analysis
Level 2: Automated Deploys and Functional Testing
Level 3: Automated Configuration Management
Level 4: Cloud Deployments
Level 5: Continuous Delivery

© Copyright 2013 Coveros, Inc. All rights reserved.

10

5
4/16/2013

Level 1: Unit Testing and Static Analysis
Unit Tests:
– Confidence to make changes
– Error handling
– General logic errors
– Bounds checking
– Edge conditions

© Copyright 2013 Coveros, Inc. All rights reserved.

11

© Copyright 2013 Coveros, Inc. All rights reserved.

12

Level 1: Unit Testing and Static Analysis
Static Analysis:
– Common errors
– Unused variables
– SQL injection
– Cross-Site Scripting (XSS)
– Hard-coded passwords

6
4/16/2013

Level 1: Unit Testing and Static Analysis
Unit testing:
JUnit for Java
NUnit for .Net
PyUnit for Python
PHPUnit for PHP
Static Analysis:
Sonar for many languages
PMD for Java
FindBugs for Java
PHPMD for PHP
FxCop for .Net
PyChecker for Python
pylint for Python
© Copyright 2013 Coveros, Inc. All rights reserved.

13

Maturity Model for Security Testing
Level 0: No Security Testing
Level 1: Unit Testing and Static Analysis
Level 2: Automated Deploys and Functional Testing
Level 3: Automated Configuration Management
Level 4: Cloud Deployments
Level 5: Continuous Delivery

© Copyright 2013 Coveros, Inc. All rights reserved.

14

7
4/16/2013

Level 2: Automated Deploys and Functional Testing
Automated Deploys:
– Frequent security scans
– Rapid feedback
– Web application scanners:
w3af
wapiti
Skipfish
– Start basic, add tuning

© Copyright 2013 Coveros, Inc. All rights reserved.

15

Level 2: Automated Deploys and Functional Testing
Functional Testing:
– Access control
– Data protection
– Web Application testing:
Selenium

© Copyright 2013 Coveros, Inc. All rights reserved.

16

8
4/16/2013

Level 2: Automated Deploys and Functional Testing
Proxies:
– Better coverage
– XSS and Cross-Site Request Forgery (XSRF)
– Data leakage
– URLs for logs to augment spidering
– Web application proxies:
OWASP Zed Attack Proxy (ZAP) Project
OWASP WebScarab
Ratproxy

© Copyright 2013 Coveros, Inc. All rights reserved.

17

Maturity Model for Security Testing
Level 0: No Security Testing
Level 1: Unit Testing and Static Analysis
Level 2: Automated Deploys and Functional Testing
Level 3: Automated Configuration Management
Level 4: Cloud Deployments
Level 5: Continuous Delivery

© Copyright 2013 Coveros, Inc. All rights reserved.

18

9
4/16/2013

Level 3: Automated Configuration Management
Deployment/Configuration:
Puppet
Chef
Provisioning:
Cobbler
Kickstart
Windows Deployment Services
Completely new systems or build on templates
Repeatable configuration management

© Copyright 2013 Coveros, Inc. All rights reserved.

19

Level 3: Automated Configuration Management
Complete system scans
OpenVAS
Nmap
Nikto2

© Copyright 2013 Coveros, Inc. All rights reserved.

20

10
4/16/2013

Maturity Model for Security Testing
Level 0: No Security Testing
Level 1: Unit Testing and Static Analysis
Level 2: Automated Deploys and Functional Testing
Level 3: Automated Configuration Management
Level 4: Cloud Deployments
Level 5: Continuous Delivery

© Copyright 2013 Coveros, Inc. All rights reserved.

21

Level 4: Cloud Deployments
On-demand environments
– Long running scans in parallel
– Production-sized machines, even temporarily
– Failover and high-availability
Multiple client systems in parallel
– Race conditions
– Multi-user interactions

© Copyright 2013 Coveros, Inc. All rights reserved.

22

11
4/16/2013

Level 4: Cloud Deployments
Web performance testing frameworks:
Apache Jmeter: Java-based UI
• HTTP, HTTPS, SOAP, JDBC, LDAP, JMS, SMTP,
POP, IMAP
ab, ApacheBench: command-line
The Grinder: Jython and Clojure
Gatling: Scala

© Copyright 2013 Coveros, Inc. All rights reserved.

23

Maturity Model for Security Testing
Level 0: No Security Testing
Level 1: Unit Testing and Static Analysis
Level 2: Automated Deploys and Functional Testing
Level 3: Automated Configuration Management
Level 4: Cloud Deployments
Level 5: Continuous Delivery

© Copyright 2013 Coveros, Inc. All rights reserved.

24

12
4/16/2013

Level 5: Continuous Delivery
Release ready for production
Continuous deployment
High levels of automation
Dashboards
– Custom development

© Copyright 2013 Coveros, Inc. All rights reserved.

25

Personal Experience
Agile development grew into Continuous Delivery
Automated deploys with Puppet
Selenium functional tests
JMeter performance tests

© Copyright 2013 Coveros, Inc. All rights reserved.

26

13
4/16/2013

Personal Experience
Security testing lagged
Excuses:
– The “official” tool is expensive.
– It would take a lot of time to acquire and then to
configure it.
– We don’t have time.
– It isn’t our responsibility.
– The security team wouldn’t accept our scans anyway.
Open-source tools
Focus on security, not compliance
Limited time
© Copyright 2013 Coveros, Inc. All rights reserved.

27

© Copyright 2013 Coveros, Inc. All rights reserved.

28

Personal Experience
Web application scans with w3af
Vulnerability assessments with OpenVAS
Security standards checks with Openscap
Initial implementation ~ a day each
No more freebies

14
4/16/2013

Conclusion
Earlier security testing
– Less likely to skip
– More likely to remediate
Open-source tools
Other testing as foundation
Gradually add more security tests
Continuous Delivery and Cloud Computing give security
testing opportunities

© Copyright 2013 Coveros, Inc. All rights reserved.

29

© Copyright 2013 Coveros, Inc. All rights reserved.

30

Questions?

15
Better Security Testing Using the Cloud
and Continuous Delivery
Gene Gotimer
Coveros, Inc.

Security testing is often put off as one of the last tasks of the development cycle. So when the security
scans or reviews find vulnerabilities, businesses can be put in the position of remediating the security
issues appropriately and delaying a release or keeping a release on schedule and accepting the risks.
Those risks are not always clearly understood and almost never have a clear dollar figure associated with
them. Without really knowing what they are getting into, security remediation may be dropped and the
security testing treated as a checkbox that “we ran the security test tool” with no action being taken as a
result.
It is easy to see how security testing can become an afterthought or a second-class citizen during the
development process. It becomes a question of return on investment (ROI). To make a stronger case for
additional security testing we either have to increase the return or decrease the investment.
There is good news. Open-source and free security testing tools are growing in popularity and capability.
A development team can quickly (and, if needed, quietly) add security testing tools to their process,
without procuring an expensive security tool. That reduces the cost of the initial investment and may
eliminate some barriers to entry.
And it turns out that Cloud initiatives and efforts towards Continuous Delivery (CD) not only have some
great benefits of their own, but can also provide some opportunities to get security testing in place
without a large outlay of resources. For a team that is trying to increase their security testing as cheaply
as possible, there are plenty of chances to add it to their process almost for free.
Those will be the focus of my discussion: low effort opportunities to integrate security testing into the
development process, and the free and open-source tools that can make it practical.
While I will focus on free and open-source tools, commercial tools can be better and easier to use. A
more mature security testing practice may choose to use the commercial tool instead. Commercial tools
may already be available in your organization, which can ease adoption by being already paid for, by
being easier to use, by being more capable, and especially by having some people in your organization
that can help you use the tool and interpret the results.

Continuous Integration
Continuous integration (CI) is the practice of merging the work from multiple developers frequently,
often multiple times per day. It almost always involves frequent code commits to a source control
system and running unit tests on each and every commit. The primary benefit is that there is no long
1
cycle of integration at the end of the development cycle with developers scrambling to make all our
code work together. Plus, as the unit tests and the integration efforts find problems, we make
adjustments to our code while it is fresh in the developer’s minds. Developers get into a build-testcommit cycle which gives us rapid feedback and makes working, unit-tested code available to the rest of
the team on a continuous basis.

Continuous Delivery
Continuous delivery is a software development process that aims to have every build releasable to
production. It may not be released, but everyone involved will be able to make an informed business
decision to release that software without having to guess whether or not it will work.
Continuous delivery can be viewed as the logical extrapolation of continuous integration. After running
the normal unit tests on the code, we frequently deploy code and run other tests, such as functional
tests, load and performance tests, and even security tests. By extending the CI concept of build-testcommit to be build-test-commit-deploy-test-release, we can extend the rapid feedback cycle all the way
out to production releases, or at least to the point of releasable software. And instead of just having
unit-tested code available to the other developers, now we have production-ready code available to the
business.
Enabling continuous delivery means adding automation to deploys, so that deploys can happen without
a lot of effort. If it is expensive in terms of time and effort to deploy, it won’t be done often. And if it
isn’t automated, it won’t be repeatable and consistent. Not only do deploys to our test environments
become non-events, but we know when we push into production that the deploy process will work the
same way. After all, the deploy process has been tested just as often as the code has.

Cloud Computing
Cloud computing has brought a new economy to acquiring and provisioning computing resources. Along
with that, the cloud has brought a new wave of tools to make configuration management and software
deployment capable of exploiting that new found speed and low costs.
Because we are deploying on a rapid schedule, we can’t wait for the normal weeks-to-months long
procurement and installation cycles to get hardware ready for us to deploy to. With cloud computing,
the procurement cycle can be minutes long. And the investment per project is usually lower, too.
If we use a public cloud like Amazon, cloud services are always available for ordering. Virtually any
amount of computing power can be ordered whenever we need it. Private cloud computing resources
are often pooled, so when we are done using them the resources can be returned to the pool for other
teams to use.
Cloud computing has a symbiotic relationship with continuous delivery. Deploys are easy because they
are automated, so we have less of a barrier to standing up new environments. And establishing new

2
environments in the cloud is easy, so we can stand one up from scratch whenever it would be
convenient to have another instance of the application deployed.

Maturity Model for Security Testing
To grow a security testing practice, we need to first take stock of where we stand now. Then we need to
have some path to follow, milestones to shoot for, and some way to measure if we are making
improvements or not. One way to measure our current state and chart our growth is a maturity model.
We’ll start by setting the scale. The levels might be good for comparing the maturity of security testing
between two different projects, but they are really just intended as an example of milestones to aim for.
Each level represents an opportunity to introduce new security tests and security testing tools into the
process. The progression ranges from introducing security testing to an established practice and onto
advancing and refining your security testing capabilities.
•
•
•
•
•
•

Level 0: No Security Testing
Level 1: Unit Testing and Static Analysis
Level 2: Automated Deploys and Functional Testing
Level 3: Automated Configuration Management
Level 4: Cloud Deployments
Level 5: Continuous Delivery

These levels aren’t equally spaced in time or effort to achieve them. Going from nothing to unit tests
and static analysis is much easier than going from automated configuration management to cloud
deployments. In general, the more mature the practice, the more effort it will require to incorporate the
next practice. The early ones are the types of testing we can add almost for free, while the later
practices require a lot of discipline and a committed effort.
Largely for this reason, not every project will benefit from working towards the ultimate level. It might
be sufficient to unit test and do static analysis on an internal utility with a limited lifespan and no
sensitive data or access, while an online ordering system available to the public certainly needs more
security attention. What constitutes “enough” security testing has to be determined for each project.

Level 0: No Security Testing
The initial state is no security testing. We’ll score that as a zero. Unfortunately, far too many projects
start and end here. The good news is that if we start here, even the slightest bit of improvement is a
win.

Level 1: Unit Testing and Static Analysis
The next step, barely doing any security testing, is very easy to integrate into our development process:
simply add unit testing and static analysis. You might not normally file those under security tests, but
they are a good foot in the door and if you are doing CI you probably have these already.

3
Perhaps the biggest advantage of having good unit tests is the confidence that we can make changes to
an application safely, without making unintended changes to behavior. That decreases the risks involved
with any code changes, including security remediation, even late in the development cycle. This makes
unit testing a critical practice as the foundation for any development.
Through normal efforts in unit testing, most developers will start testing edge cases and failure cases.
For example,
•
•
•
•

What happens if we have no items in the list we are iterating through?
What happens when we expect 5 items but only get 4?
How do we handle a file not found when we try to read a configuration file?
What if the file is found but not in the correct format?

Poor handling of these types of errors can lead to some common type of security vulnerabilities: error
handling, general logic errors, bounds checking, etc. Unit testing is well-suited to identifying some of
these error types since the units are tested independently. Fewer assumptions about the input and
program state are made, so the units are able to better stand on their own. As a result, it can be easier
to test each unit more thoroughly for undesirable or unexpected conditions. Adding a code coverage
tool can help us identify edge conditions and testing opportunities that we missed initially.
Static analysis tools look at source code or compiled code, looking for common errors, unused variables,
style and formatting variations, and similar items. Like unit tests, static analysis tools can identify some
potential security problems:
•
•
•
•

Are inputs validated?
Are outputs escaped?
Is the source code hard to understand, and therefore easy for other developers to misuse?
Is there a lot of duplicated source code? If we fix a bug once will the same problem crop up
in other places?

Most modern languages have a selection of open-source static analysis tools that can scan source code
looking for predictable problems. SQL injection, Cross-Site Scripting (XSS), and hard-coded passwords
are common vulnerabilities that can often be detected by static code analysis.
With a CI practice, it is easy to configure unit testing and static code analysis to run on every commit or
at least every night. We can make it part of a project’s boilerplate build scripts and/or even enable it in
our CI engine with little more than the click of a configuration checkbox.
Just adding unit testing or static analysis isn’t a comprehensive security testing process, but it is easy to
get started and is far better than nothing. And we need to have these anyway.
Here are some suggestions for some free and/or open-source tools to get started:

4
•

•

Unit testing:




Static Analysis:








JUnit for Java, http://junit.org
NUnit for .Net, http://www.nunit.org
PyUnit for Python, http://pyunit.sourceforge.net
PHPUnit for PHP, http://www.phpunit.de
Sonar for many languages, http://www.sonarsource.org
PMD for Java, http://pmd.sourceforge.net
FindBugs for Java, http://findbugs.sourceforge.net
PHPMD for PHP, http://phpmd.org
FxCop for .Net, http://msdn.microsoft.com/en-us/library/bb429476.aspx
PyChecker for Python, http://pychecker.sourceforge.net
pylint for Python, http://www.pylint.org

Level 2: Automated Deploys and Functional Testing
Automated deploys are the first step most teams think of when they start working towards continuous
delivery. Automated deploys also open up some opportunities for more focused security testing.
The most obvious opportunity is just being able to scan the deployed application on a frequent basis. If
we can deploy automatically, then we can kick off security tests after we deploy and get a scan early in
the development cycle. We can investigate and remediate vulnerabilities we find before it is too late to
address them.
Even better, if we can trigger a deploy and scan using our CI engine, then developers can get same-day
or next-day feedback that shows that they may have introduced a security issue. They can fix problems
while the code is still fresh on their minds.
The easiest way to start scanning an automated deploy is with black-box tools that can just be pointed
at the deployed application and need little-to-no configuration initially. Some examples for web
applications include:
•
•
•

w3af, http://w3af.org
wapiti, http://wapiti.sourceforge.net
Skipfish, http://code.google.com/p/skipfish/

While these tools can (and should) eventually be tuned to better suit our application, even the most
basic scans can provide a wealth of information. Simple tuning can usually limit runtimes to be short
enough to fit the situation. For example, every hour we could run a quick, superficial scan that takes 10
minutes and then overnight we could run a more detailed scan.
Automated deployments also ease automated functional testing. In addition to the normal user
behavior tests, we can use functional tests to test access controls and data protection. User roles can be
very thoroughly tested using automated functional tests, especially when doing negative testing. For

5
example, a user should be able to see their account information, but not someone else’s. Users with one
role should be able to access certain functionality, but not other functionality.
The most popular open source functional test framework for web applications is Selenium
(http://seleniumhq.org), although there are plenty of good alternatives. There are also many good
options for applications that aren’t web-based or browser-based, such as web services.
Having those tests automated means they can be run frequently, and they become a great shield against
regression bugs and unintended data leakage. Like unit tests, the strongest advantage of automated
functional tests is that changes can be made to individual features without introducing unwanted
behavior changes. If we enable a role to view a new aggregate report, did those users also get the ability
to view someone else data? If we explicitly add the ability for a role to see another user’s data, are they
still prohibited from making changes to it?
If we combine the automated functional tests with security scanning we get some very good insight into
possible vulnerabilities. Running the functional tests through a proxy can uncover XSS and Cross-Site
Request Forgery (XSRF) issues that a typical web scanner could not reach without login credentials or
complex combinations of actions, for example. Proxies can also help find unintended external data
leakage, such as a finding that a third-party library uses a public web service to generate charts.
Collecting URLs from web access logs that were accessed during functional tests can be a great addition
to spidering targets for web application scanners.
Free web application proxies include:
•
•
•

OWASP Zed Attack Proxy (ZAP) Project,
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
OWASP WebScarab,
https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
Ratproxy, http://code.google.com/p/ratproxy/

Level 3: Automated Configuration Management
Configuration management means different things to different people, but I am referring to being able
to determine and recreate the state of a computer system: OS, configuration files and settings, package
versions, dependency versions, etc.
Frameworks such as Puppet (https://puppetlabs.com/puppet/puppet-open-source/) and Chef
(http://www.opscode.com/chef/) are gaining a lot of traction for handling automated configuration
management functions. They allow package versions, file permissions and ownership, and network
services to be specified and controlled in code, rather than a list of manual steps a system administrator
must remember to follow upon installation.
Puppet and Chef can be used alongside tools such as Cobbler (http://cobbler.github.com/), Kickstart
(http://fedoraproject.org/wiki/Anaconda/Kickstart), or Windows Deployment Services
(http://msdn.microsoft.com/en-us/library/aa967394.aspx) to stand up a system from “bare metal”. Or
6
they can be used in conjunction with a “Gold Disk” or other standardized OS installs to completely
recreate a production-like environment and system laydown.
From a security point of view, the configuration management itself is the biggest draw. Being able to
review and specify a system configuration via code and knowing that it represents the actual system
state rather than the requested system state is invaluable during security audits. And the ability to
recreate an environment has tremendous forensic value when troubleshooting a security incident, not
to mention simply being able to reliably recreate production bugs in non-production environments.
Another advantage is that we can baseline (return to a known state) a complete system easily. That
means that we can run a security scan on a cleanly installed system, and the entire system can be
analyzed. Scanners like OpenVAS (http://www.openvas.org/), an open-source Nessus fork, Nmap
(http://nmap.org/), and Nikto2 (http://cirt.net/nikto2) can be used against a system to scan for
vulnerabilities via open ports and exposed services. We can schedule these tools to run regularly or
scripted to run from a CI engine. Rather than wait for a security expert to schedule a scan of our
application on a pre-production system just before release, we can scan the system every day so that we
know the results and can remediate issues during the development cycle.

Level 4: Cloud Deployment
Deploying our application in the cloud allows environments to be stood up without much time, effort, or
cost. Since we’ve already automated the deployment and the OS and system installation, now standing
up a new environment from nothing can be effortless, even without provisioned hardware.
That in turn means we can stand up an environment whenever we need it and only keep it operating
while it is in use. More projects can share fewer resources since they won’t all need the resources at the
same time. We can run long running scans, such as deep fuzzing scans, against a newly provisioned,
dedicated environment while other development efforts continue in other environments in parallel.
Also, we can execute resource intensive tests with adequate resources even if those resources cannot
be reserved indefinitely. Performance, load, and stress tests can be run on “production-sized” machines
rather than possibly undersized development systems. That can help better identify limits and reduce
the risks of denial of service attacks. Failover and high-availability systems often get tested once prior to
the initial production release, and then never tested again, only because it was too expensive to have an
entire extra set of redundant systems stood up in a test environment.
Some tests can benefit from the use of multiple client systems as well. Rather than running a many
hours of functional tests overnight and having a one-day lag between code commit and test results, we
can use cloud resources to stand up multiple client systems to run the functional tests in parallel. Not
only can we run the tests more often since they take less elapsed time, but we’ll be better able to
identify RACE conditions and multi-user interactions.
Open-source performance testing frameworks for web-based applications include:

7
•
•
•
•

Apache JMeter (http://jmeter.apache.org), which builds tests from a Java-based UI and can
test HTTP, HTTPS, SOAP, JDBC, LDAP, JMS, SMTP, POP, and IMAP, among other protocols
ab, ApacheBench (http://httpd.apache.org/docs/2.4/programs/ab.html), for command-line
driven performance tests
The Grinder (http://grinder.sourceforge.net), for load testing with tests written in Jython
and Clojure
Gatling (http://gatling-tool.org), for stress testing with tests written in Scala

Level 5: Continuous Delivery
Continuous delivery means being able to delivery software at any time. It takes releasing software from
what had been a lengthy and often risky development process to an automated process that ensure the
timing of a release is a purely business decision. It can range in practice from having a release always
ready to go should the stakeholder want to promote it to production, to continuous deployment where
the software is tested thoroughly enough that stakeholders are confident that it can be promoted
automatically, without any human decision points, whenever all automated testing reaches a “good
enough” threshold.
This stage requires a very high level of automation, so that we have enough confidence in all testing
(functional, regression, performance, and security testing) to allow unattended, automated releases.
Most software, and certainly most organizations, will never reach this level of trust in automated
testing, but it is a valuable goal.
Along with the automation itself, dashboards are important to display the results of all the various builds
and tests through the process. The more automation and testing that is involved, the more information
that has to be processed, and the more important dashboards become. The proliferation of
environments makes it critical for us to be able to quickly determine what the configuration of each
environment is, what packages are installed, what tests have been performed, and what the results of
those tests were.
Unfortunately, there aren’t any ready-to-use open-source dashboards for a continuous delivery process,
which makes sense since the process and tools can vary significantly from team to team and project to
project. We will have to develop these dashboards as they are needed.

Personal Experience
My current project is a large integration and customization project for the Department of Defense
(DoD). As part of our mission, our team was tasked to introduce an agile development process and
demonstrate how it could be used on a DoD project. That eventually became an effort to work towards
a Continuous Delivery process, and to show if and how it would work in the DoD environment.
We’ve made great progress. Over the last year we have added deploys that are almost entirely
automated using Puppet, although a few manual steps still remain. We have developed a suite of
functional tests to cover our entire system. The system is web based, and we have chosen Selenium for
8
our functional tests. We have just recently added JMeter testing to measure performance, really
focused on watching the trends as we make releases. I.e., have we made the system noticeably
faster/slower?
One item we had not addressed until well into the project was security testing. We had done it a few
times manually, but another part of the organization was responsible for the security scanning, so we
didn’t build it into our process. If that sounds like a weak justification, it is. We just kept making excuses,
such as:
•
•
•
•
•

The “official” tool is expensive.
It would take a lot of time to acquire and then to configure it.
We don’t have time.
It isn’t our responsibility.
The security team wouldn’t accept our scans anyway.

While there is a grain of truth to each of those, we finally gave it some serious thought and realized that
we already had the infrastructure and process to support some security testing, and could start doing a
lot more with very little effort.
We decided we would focus on open-source tools that paralleled what the security team would
eventually use. The more testing we did up front, the less likely we were to be surprised by findings at
the end of the cycle. Focusing on improving the security was more important for our development team
than worrying if we could satisfy compliance requirements by running particular tools. But since security
truly was the responsibility of another team, we did not have any significant time to implement our
testing.
We use w3af to do web application scanning. Our application relies on client-side certificates for login,
so we had to make some slight customizations to w3af to deal with passing a certificate in. Fortunately,
w3af is open source and written in Python, and it was easy to add the required support with just a few
lines of code. We can run w3af from our CI engine, Jenkins, but don’t often because we haven’t come up
with a convenient way to display the results. Since a manual inspection of the scan results is still
required we don’t execute the w3af scans continuously. We are working on better reporting so we can
quickly see what changes in the scans were made with the recent changes to the code.
We set up OpenVAS to do remote scans and vulnerability assessments. The scans run each weekend
against our test systems. Ten servers are scanned in parallel; the scans are completed in less than two
hours. We could scan more often, but the systems themselves don’t change open ports and installed
packages often enough to warrant it. If needed, we can start the scans on demand. OpenVAS maintains
a history of the scans and can track issues we’ve identified as false positives. It also shows changes and
overall trends in the number of vulnerabilities.
We added Openscap (http://www.open-scap.org) as part of our CI process. It runs a series of automated
checks against our systems to determine compliance with a set of security standards, which in our case
are mandated. Security Content Automation Protocol (SCAP) has a fair number of checks that must be
9
manually performed as well, but at least running the automated checks makes our compliance efforts
easier. Most importantly, we can see when a change to our system or to our application introduces or
fixes any security vulnerabilities.
Each of these security scans was initially implemented in a day or so, using down time in between other
assigned tasks. We added them to the process because they were open source, easy to introduce, and
did not slow down or complicate our existing process. Also, it was easy to interpret the results, so we
could act upon the results so that the scans had real value in our process. If you can’t understand the
findings, you can’t act on them.
On our scale of maturity, we’ve pushed through automated configuration management and are
beginning to do more cloud deployments, but our security testing is lagging a little behind that. We are
just starting to take advantage of the cloud for performance testing and slower running security scans.
On the other hand, we have a good selection of scans going on that help us ensure that our systems and
our application are more secure and more likely to meet compliance rules. Also, we find out quickly if
changes we make to the system configuration or to the application introduce any new security issues.
It seems like we’ve exhausted our “free” opportunities to increase the security testing. Most of what
we’ll add in the future will require some real focus and effort. But the groundwork we have laid is
already showing value, so garnering support for those larger efforts should be easier.

Conclusion
Doing security testing earlier in the development cycle means it is less likely to be dropped and more
likely we will remediate the problems that we find. By using open-source tools and identifying
opportunities to add security testing into our current processes, we can reduce the cost of adopting
security testing. Other, non-security testing can lay the foundation for security tests and safe
remediation. Gradually adding security testing, even little pieces of it, can quickly add value.
Whether you already have continuous delivery and cloud initiatives underway and are piggybacking on
them, or are using additional security testing potential as an argument to adopt them, the continuous
delivery process and cloud computing efforts give ample opportunities to add security testing without
much effort.

About the Author
Gene Gotimer is a senior architect at Coveros, Inc., a consulting company that uses agile methods to
accelerate the delivery of secure, reliable software. Gene is an experienced software developer who
focuses on continuous integration, static code analysis, automation, and any tool he can get to do his
work for him. For the last few years he has been on a team that is bringing a continuous delivery process
into the US Department of Defense, showing other projects that software can be delivered quicker with
more security and higher quality by using agile techniques.

10

More Related Content

What's hot

Bringing Security Testing to Development: How to Enable Developers to Act as ...
Bringing Security Testing to Development: How to Enable Developers to Act as ...Bringing Security Testing to Development: How to Enable Developers to Act as ...
Bringing Security Testing to Development: How to Enable Developers to Act as ...
Achim D. Brucker
 
Implementing an Application Security Pipeline in Jenkins
Implementing an Application Security Pipeline in JenkinsImplementing an Application Security Pipeline in Jenkins
Implementing an Application Security Pipeline in Jenkins
Suman Sourav
 
Top 5 best practice for delivering secure in-vehicle software
Top 5 best practice for delivering secure in-vehicle softwareTop 5 best practice for delivering secure in-vehicle software
Top 5 best practice for delivering secure in-vehicle software
Rogue Wave Software
 
Webinar – Risk-based adaptive DevSecOps
Webinar – Risk-based adaptive DevSecOps Webinar – Risk-based adaptive DevSecOps
Webinar – Risk-based adaptive DevSecOps
Synopsys Software Integrity Group
 
Why should developers care about container security?
Why should developers care about container security?Why should developers care about container security?
Why should developers care about container security?
Eric Smalling
 
Innovating Faster with Continuous Application Security
Innovating Faster with Continuous Application Security Innovating Faster with Continuous Application Security
Innovating Faster with Continuous Application Security
Jeff Williams
 
How-To-Guide for Software Security Vulnerability Remediation
How-To-Guide for Software Security Vulnerability RemediationHow-To-Guide for Software Security Vulnerability Remediation
How-To-Guide for Software Security Vulnerability Remediation
Denim Group
 
"CERT Secure Coding Standards" by Dr. Mark Sherman
"CERT Secure Coding Standards" by Dr. Mark Sherman"CERT Secure Coding Standards" by Dr. Mark Sherman
"CERT Secure Coding Standards" by Dr. Mark Sherman
Rinaldi Rampen
 
Building Security in Using CI
Building Security in Using CIBuilding Security in Using CI
Building Security in Using CI
Coveros, Inc.
 
Application Security at DevOps Speed and Portfolio Scale
Application Security at DevOps Speed and Portfolio ScaleApplication Security at DevOps Speed and Portfolio Scale
Application Security at DevOps Speed and Portfolio Scale
Jeff Williams
 
Understanding & Addressing OWASP’s Newest Top Ten Threat: Using Components wi...
Understanding & Addressing OWASP’s Newest Top Ten Threat: Using Components wi...Understanding & Addressing OWASP’s Newest Top Ten Threat: Using Components wi...
Understanding & Addressing OWASP’s Newest Top Ten Threat: Using Components wi...
Sonatype
 
Remediation Statistics: What Does Fixing Application Vulnerabilities Cost?
Remediation Statistics: What Does Fixing Application Vulnerabilities Cost?Remediation Statistics: What Does Fixing Application Vulnerabilities Cost?
Remediation Statistics: What Does Fixing Application Vulnerabilities Cost?
Denim Group
 
ABC's of Service Virtualization
ABC's of Service VirtualizationABC's of Service Virtualization
ABC's of Service Virtualization
Parasoft
 
AppSec How-To: Achieving Security in DevOps
AppSec How-To: Achieving Security in DevOpsAppSec How-To: Achieving Security in DevOps
AppSec How-To: Achieving Security in DevOps
Checkmarx
 
2017-11 Three Ways of Security - OWASP London
2017-11 Three Ways of Security - OWASP London2017-11 Three Ways of Security - OWASP London
2017-11 Three Ways of Security - OWASP London
Jeff Williams
 
OWASP - Building Secure Web Applications
OWASP - Building Secure Web ApplicationsOWASP - Building Secure Web Applications
OWASP - Building Secure Web Applications
alexbe
 
Third Party Performance (Velocity, 2014)
Third Party Performance (Velocity, 2014)Third Party Performance (Velocity, 2014)
Third Party Performance (Velocity, 2014)
Guy Podjarny
 
Symposium AFAI Cybersecurity CSX ISACA
Symposium AFAI Cybersecurity CSX ISACASymposium AFAI Cybersecurity CSX ISACA
Symposium AFAI Cybersecurity CSX ISACA
Antoine Vigneron
 
DevSecOps | DevOps Sec
DevSecOps | DevOps SecDevSecOps | DevOps Sec
DevSecOps | DevOps Sec
Rubal Jain
 
The Self Healing Cloud: Protecting Applications and Infrastructure with Autom...
The Self Healing Cloud: Protecting Applications and Infrastructure with Autom...The Self Healing Cloud: Protecting Applications and Infrastructure with Autom...
The Self Healing Cloud: Protecting Applications and Infrastructure with Autom...
Denim Group
 

What's hot (20)

Bringing Security Testing to Development: How to Enable Developers to Act as ...
Bringing Security Testing to Development: How to Enable Developers to Act as ...Bringing Security Testing to Development: How to Enable Developers to Act as ...
Bringing Security Testing to Development: How to Enable Developers to Act as ...
 
Implementing an Application Security Pipeline in Jenkins
Implementing an Application Security Pipeline in JenkinsImplementing an Application Security Pipeline in Jenkins
Implementing an Application Security Pipeline in Jenkins
 
Top 5 best practice for delivering secure in-vehicle software
Top 5 best practice for delivering secure in-vehicle softwareTop 5 best practice for delivering secure in-vehicle software
Top 5 best practice for delivering secure in-vehicle software
 
Webinar – Risk-based adaptive DevSecOps
Webinar – Risk-based adaptive DevSecOps Webinar – Risk-based adaptive DevSecOps
Webinar – Risk-based adaptive DevSecOps
 
Why should developers care about container security?
Why should developers care about container security?Why should developers care about container security?
Why should developers care about container security?
 
Innovating Faster with Continuous Application Security
Innovating Faster with Continuous Application Security Innovating Faster with Continuous Application Security
Innovating Faster with Continuous Application Security
 
How-To-Guide for Software Security Vulnerability Remediation
How-To-Guide for Software Security Vulnerability RemediationHow-To-Guide for Software Security Vulnerability Remediation
How-To-Guide for Software Security Vulnerability Remediation
 
"CERT Secure Coding Standards" by Dr. Mark Sherman
"CERT Secure Coding Standards" by Dr. Mark Sherman"CERT Secure Coding Standards" by Dr. Mark Sherman
"CERT Secure Coding Standards" by Dr. Mark Sherman
 
Building Security in Using CI
Building Security in Using CIBuilding Security in Using CI
Building Security in Using CI
 
Application Security at DevOps Speed and Portfolio Scale
Application Security at DevOps Speed and Portfolio ScaleApplication Security at DevOps Speed and Portfolio Scale
Application Security at DevOps Speed and Portfolio Scale
 
Understanding & Addressing OWASP’s Newest Top Ten Threat: Using Components wi...
Understanding & Addressing OWASP’s Newest Top Ten Threat: Using Components wi...Understanding & Addressing OWASP’s Newest Top Ten Threat: Using Components wi...
Understanding & Addressing OWASP’s Newest Top Ten Threat: Using Components wi...
 
Remediation Statistics: What Does Fixing Application Vulnerabilities Cost?
Remediation Statistics: What Does Fixing Application Vulnerabilities Cost?Remediation Statistics: What Does Fixing Application Vulnerabilities Cost?
Remediation Statistics: What Does Fixing Application Vulnerabilities Cost?
 
ABC's of Service Virtualization
ABC's of Service VirtualizationABC's of Service Virtualization
ABC's of Service Virtualization
 
AppSec How-To: Achieving Security in DevOps
AppSec How-To: Achieving Security in DevOpsAppSec How-To: Achieving Security in DevOps
AppSec How-To: Achieving Security in DevOps
 
2017-11 Three Ways of Security - OWASP London
2017-11 Three Ways of Security - OWASP London2017-11 Three Ways of Security - OWASP London
2017-11 Three Ways of Security - OWASP London
 
OWASP - Building Secure Web Applications
OWASP - Building Secure Web ApplicationsOWASP - Building Secure Web Applications
OWASP - Building Secure Web Applications
 
Third Party Performance (Velocity, 2014)
Third Party Performance (Velocity, 2014)Third Party Performance (Velocity, 2014)
Third Party Performance (Velocity, 2014)
 
Symposium AFAI Cybersecurity CSX ISACA
Symposium AFAI Cybersecurity CSX ISACASymposium AFAI Cybersecurity CSX ISACA
Symposium AFAI Cybersecurity CSX ISACA
 
DevSecOps | DevOps Sec
DevSecOps | DevOps SecDevSecOps | DevOps Sec
DevSecOps | DevOps Sec
 
The Self Healing Cloud: Protecting Applications and Infrastructure with Autom...
The Self Healing Cloud: Protecting Applications and Infrastructure with Autom...The Self Healing Cloud: Protecting Applications and Infrastructure with Autom...
The Self Healing Cloud: Protecting Applications and Infrastructure with Autom...
 

Viewers also liked

Testing—After You’ve Finished Testing
Testing—After You’ve Finished TestingTesting—After You’ve Finished Testing
Testing—After You’ve Finished Testing
TechWell
 
Exploratory Testing Is Now in Session
Exploratory Testing Is Now in SessionExploratory Testing Is Now in Session
Exploratory Testing Is Now in Session
TechWell
 
Keynote: Lightning Strikes the Keynotes
Keynote: Lightning Strikes the KeynotesKeynote: Lightning Strikes the Keynotes
Keynote: Lightning Strikes the Keynotes
TechWell
 
Innovations in Test Automation: It’s Not All about Regression
Innovations in Test Automation: It’s Not All about RegressionInnovations in Test Automation: It’s Not All about Regression
Innovations in Test Automation: It’s Not All about Regression
TechWell
 
New Testing Standards Are on the Horizon: What Will Be Their Impact?
New Testing Standards Are on the Horizon: What Will Be Their Impact?New Testing Standards Are on the Horizon: What Will Be Their Impact?
New Testing Standards Are on the Horizon: What Will Be Their Impact?
TechWell
 
Tune Agile Test Strategies to Project and Product Maturity
Tune Agile Test Strategies to Project and Product MaturityTune Agile Test Strategies to Project and Product Maturity
Tune Agile Test Strategies to Project and Product Maturity
TechWell
 
Build Your Own Performance Test Lab in the Cloud
Build Your Own Performance Test Lab in the CloudBuild Your Own Performance Test Lab in the Cloud
Build Your Own Performance Test Lab in the Cloud
TechWell
 
Introducing Mobile Testing to Your Organization
Introducing Mobile Testing to Your OrganizationIntroducing Mobile Testing to Your Organization
Introducing Mobile Testing to Your Organization
TechWell
 
How Spotify Tests World Class Apps
How Spotify Tests World Class AppsHow Spotify Tests World Class Apps
How Spotify Tests World Class Apps
TechWell
 
Maybe We Don’t Have to Test It
Maybe We Don’t Have to Test ItMaybe We Don’t Have to Test It
Maybe We Don’t Have to Test It
TechWell
 
Keynote: Lean Software Delivery: Synchronizing Cadence with Context
Keynote: Lean Software Delivery: Synchronizing Cadence with ContextKeynote: Lean Software Delivery: Synchronizing Cadence with Context
Keynote: Lean Software Delivery: Synchronizing Cadence with Context
TechWell
 
Planning Your Agile Testing: A Practical Guide
Planning Your Agile Testing: A Practical GuidePlanning Your Agile Testing: A Practical Guide
Planning Your Agile Testing: A Practical Guide
TechWell
 
Specification-by-Example: A Cucumber Implementation
Specification-by-Example: A Cucumber ImplementationSpecification-by-Example: A Cucumber Implementation
Specification-by-Example: A Cucumber Implementation
TechWell
 
Pay Now or Pay More Every Day: Reduce Technical Debt Now!
Pay Now or Pay More Every Day: Reduce Technical Debt Now!Pay Now or Pay More Every Day: Reduce Technical Debt Now!
Pay Now or Pay More Every Day: Reduce Technical Debt Now!
TechWell
 
It Seemed a Good Idea at the Time: Intelligent Mistakes in Test Automation
It Seemed a Good Idea at the Time: Intelligent Mistakes in Test AutomationIt Seemed a Good Idea at the Time: Intelligent Mistakes in Test Automation
It Seemed a Good Idea at the Time: Intelligent Mistakes in Test Automation
TechWell
 
Exploratory Testing Explained
Exploratory Testing ExplainedExploratory Testing Explained
Exploratory Testing Explained
TechWell
 

Viewers also liked (16)

Testing—After You’ve Finished Testing
Testing—After You’ve Finished TestingTesting—After You’ve Finished Testing
Testing—After You’ve Finished Testing
 
Exploratory Testing Is Now in Session
Exploratory Testing Is Now in SessionExploratory Testing Is Now in Session
Exploratory Testing Is Now in Session
 
Keynote: Lightning Strikes the Keynotes
Keynote: Lightning Strikes the KeynotesKeynote: Lightning Strikes the Keynotes
Keynote: Lightning Strikes the Keynotes
 
Innovations in Test Automation: It’s Not All about Regression
Innovations in Test Automation: It’s Not All about RegressionInnovations in Test Automation: It’s Not All about Regression
Innovations in Test Automation: It’s Not All about Regression
 
New Testing Standards Are on the Horizon: What Will Be Their Impact?
New Testing Standards Are on the Horizon: What Will Be Their Impact?New Testing Standards Are on the Horizon: What Will Be Their Impact?
New Testing Standards Are on the Horizon: What Will Be Their Impact?
 
Tune Agile Test Strategies to Project and Product Maturity
Tune Agile Test Strategies to Project and Product MaturityTune Agile Test Strategies to Project and Product Maturity
Tune Agile Test Strategies to Project and Product Maturity
 
Build Your Own Performance Test Lab in the Cloud
Build Your Own Performance Test Lab in the CloudBuild Your Own Performance Test Lab in the Cloud
Build Your Own Performance Test Lab in the Cloud
 
Introducing Mobile Testing to Your Organization
Introducing Mobile Testing to Your OrganizationIntroducing Mobile Testing to Your Organization
Introducing Mobile Testing to Your Organization
 
How Spotify Tests World Class Apps
How Spotify Tests World Class AppsHow Spotify Tests World Class Apps
How Spotify Tests World Class Apps
 
Maybe We Don’t Have to Test It
Maybe We Don’t Have to Test ItMaybe We Don’t Have to Test It
Maybe We Don’t Have to Test It
 
Keynote: Lean Software Delivery: Synchronizing Cadence with Context
Keynote: Lean Software Delivery: Synchronizing Cadence with ContextKeynote: Lean Software Delivery: Synchronizing Cadence with Context
Keynote: Lean Software Delivery: Synchronizing Cadence with Context
 
Planning Your Agile Testing: A Practical Guide
Planning Your Agile Testing: A Practical GuidePlanning Your Agile Testing: A Practical Guide
Planning Your Agile Testing: A Practical Guide
 
Specification-by-Example: A Cucumber Implementation
Specification-by-Example: A Cucumber ImplementationSpecification-by-Example: A Cucumber Implementation
Specification-by-Example: A Cucumber Implementation
 
Pay Now or Pay More Every Day: Reduce Technical Debt Now!
Pay Now or Pay More Every Day: Reduce Technical Debt Now!Pay Now or Pay More Every Day: Reduce Technical Debt Now!
Pay Now or Pay More Every Day: Reduce Technical Debt Now!
 
It Seemed a Good Idea at the Time: Intelligent Mistakes in Test Automation
It Seemed a Good Idea at the Time: Intelligent Mistakes in Test AutomationIt Seemed a Good Idea at the Time: Intelligent Mistakes in Test Automation
It Seemed a Good Idea at the Time: Intelligent Mistakes in Test Automation
 
Exploratory Testing Explained
Exploratory Testing ExplainedExploratory Testing Explained
Exploratory Testing Explained
 

Similar to Better Security Testing: Using the Cloud and Continuous Delivery

Better Security Testing: Using the Cloud and Continuous Delivery
Better Security Testing: Using the Cloud and Continuous Delivery Better Security Testing: Using the Cloud and Continuous Delivery
Better Security Testing: Using the Cloud and Continuous Delivery
Coveros, Inc.
 
How the Cloud Shifts the Burden of Security to Development
How the Cloud Shifts the Burden of Security to DevelopmentHow the Cloud Shifts the Burden of Security to Development
How the Cloud Shifts the Burden of Security to Development
Erika Barron
 
Proposal Defense Presentation Template.pptx
Proposal Defense Presentation Template.pptxProposal Defense Presentation Template.pptx
Proposal Defense Presentation Template.pptx
UsamaAli119043
 
The best way to design secure software products
The best way to design secure software productsThe best way to design secure software products
The best way to design secure software products
LabSharegroup
 
Integrating Automated Testing into DevOps
Integrating Automated Testing into DevOpsIntegrating Automated Testing into DevOps
Integrating Automated Testing into DevOps
TechWell
 
Experience Sharing on School Pentest Project (Updated)
Experience Sharing on School Pentest Project (Updated)Experience Sharing on School Pentest Project (Updated)
Experience Sharing on School Pentest Project (Updated)
eLearning Consortium 電子學習聯盟
 
IBM Relay 2015: Securing the Future
IBM Relay 2015: Securing the Future IBM Relay 2015: Securing the Future
IBM Relay 2015: Securing the Future
IBM
 
Making the Shift from DevOps to Practical DevSecOps | Sumo Logic Webinar
Making the Shift from DevOps to Practical DevSecOps | Sumo Logic WebinarMaking the Shift from DevOps to Practical DevSecOps | Sumo Logic Webinar
Making the Shift from DevOps to Practical DevSecOps | Sumo Logic Webinar
Sumo Logic
 
Cloud testing solutions
Cloud testing solutions Cloud testing solutions
Cloud testing solutions
V2Soft2
 
Kovair DevSecOps Capabilities Overview
Kovair DevSecOps Capabilities OverviewKovair DevSecOps Capabilities Overview
Kovair DevSecOps Capabilities Overview
Kovair
 
Devops security-An Insight into Secure-SDLC
Devops security-An Insight into Secure-SDLCDevops security-An Insight into Secure-SDLC
Devops security-An Insight into Secure-SDLC
Suman Sourav
 
Measures to ensure Cyber Security in a serverless environment
Measures to ensure Cyber Security in a serverless environmentMeasures to ensure Cyber Security in a serverless environment
Measures to ensure Cyber Security in a serverless environment
Fibonalabs
 
Next generation software testing trends
Next generation software testing trendsNext generation software testing trends
Next generation software testing trends
Arun Kulkarni
 
Mobile App Testing Strategy by RapidValue Solutions
Mobile App Testing Strategy by RapidValue SolutionsMobile App Testing Strategy by RapidValue Solutions
Mobile App Testing Strategy by RapidValue Solutions
RapidValue
 
Testing with a Rooted Mobile Device
Testing with a Rooted Mobile DeviceTesting with a Rooted Mobile Device
Testing with a Rooted Mobile Device
TechWell
 
Mobile Testing Tools 101
Mobile Testing Tools 101Mobile Testing Tools 101
Mobile Testing Tools 101
TechWell
 
클라우드 환경에서의 SIEMLESS 통합 보안 서비스, Alert Logic - 채현주 보안기술본부장, Openbase :: AWS Sum...
클라우드 환경에서의 SIEMLESS 통합 보안 서비스, Alert Logic - 채현주 보안기술본부장, Openbase :: AWS Sum...클라우드 환경에서의 SIEMLESS 통합 보안 서비스, Alert Logic - 채현주 보안기술본부장, Openbase :: AWS Sum...
클라우드 환경에서의 SIEMLESS 통합 보안 서비스, Alert Logic - 채현주 보안기술본부장, Openbase :: AWS Sum...
Amazon Web Services Korea
 
Penetration testing dont just leave it to chance
Penetration testing dont just leave it to chancePenetration testing dont just leave it to chance
Penetration testing dont just leave it to chance
Dr. Anish Cheriyan (PhD)
 
How automation can help boost security
How automation can help boost securityHow automation can help boost security
How automation can help boost security
TestingXperts
 
How Real Device Cloud Testing Ensures Exceptional Efficiency and Scalability ...
How Real Device Cloud Testing Ensures Exceptional Efficiency and Scalability ...How Real Device Cloud Testing Ensures Exceptional Efficiency and Scalability ...
How Real Device Cloud Testing Ensures Exceptional Efficiency and Scalability ...
kalichargn70th171
 

Similar to Better Security Testing: Using the Cloud and Continuous Delivery (20)

Better Security Testing: Using the Cloud and Continuous Delivery
Better Security Testing: Using the Cloud and Continuous Delivery Better Security Testing: Using the Cloud and Continuous Delivery
Better Security Testing: Using the Cloud and Continuous Delivery
 
How the Cloud Shifts the Burden of Security to Development
How the Cloud Shifts the Burden of Security to DevelopmentHow the Cloud Shifts the Burden of Security to Development
How the Cloud Shifts the Burden of Security to Development
 
Proposal Defense Presentation Template.pptx
Proposal Defense Presentation Template.pptxProposal Defense Presentation Template.pptx
Proposal Defense Presentation Template.pptx
 
The best way to design secure software products
The best way to design secure software productsThe best way to design secure software products
The best way to design secure software products
 
Integrating Automated Testing into DevOps
Integrating Automated Testing into DevOpsIntegrating Automated Testing into DevOps
Integrating Automated Testing into DevOps
 
Experience Sharing on School Pentest Project (Updated)
Experience Sharing on School Pentest Project (Updated)Experience Sharing on School Pentest Project (Updated)
Experience Sharing on School Pentest Project (Updated)
 
IBM Relay 2015: Securing the Future
IBM Relay 2015: Securing the Future IBM Relay 2015: Securing the Future
IBM Relay 2015: Securing the Future
 
Making the Shift from DevOps to Practical DevSecOps | Sumo Logic Webinar
Making the Shift from DevOps to Practical DevSecOps | Sumo Logic WebinarMaking the Shift from DevOps to Practical DevSecOps | Sumo Logic Webinar
Making the Shift from DevOps to Practical DevSecOps | Sumo Logic Webinar
 
Cloud testing solutions
Cloud testing solutions Cloud testing solutions
Cloud testing solutions
 
Kovair DevSecOps Capabilities Overview
Kovair DevSecOps Capabilities OverviewKovair DevSecOps Capabilities Overview
Kovair DevSecOps Capabilities Overview
 
Devops security-An Insight into Secure-SDLC
Devops security-An Insight into Secure-SDLCDevops security-An Insight into Secure-SDLC
Devops security-An Insight into Secure-SDLC
 
Measures to ensure Cyber Security in a serverless environment
Measures to ensure Cyber Security in a serverless environmentMeasures to ensure Cyber Security in a serverless environment
Measures to ensure Cyber Security in a serverless environment
 
Next generation software testing trends
Next generation software testing trendsNext generation software testing trends
Next generation software testing trends
 
Mobile App Testing Strategy by RapidValue Solutions
Mobile App Testing Strategy by RapidValue SolutionsMobile App Testing Strategy by RapidValue Solutions
Mobile App Testing Strategy by RapidValue Solutions
 
Testing with a Rooted Mobile Device
Testing with a Rooted Mobile DeviceTesting with a Rooted Mobile Device
Testing with a Rooted Mobile Device
 
Mobile Testing Tools 101
Mobile Testing Tools 101Mobile Testing Tools 101
Mobile Testing Tools 101
 
클라우드 환경에서의 SIEMLESS 통합 보안 서비스, Alert Logic - 채현주 보안기술본부장, Openbase :: AWS Sum...
클라우드 환경에서의 SIEMLESS 통합 보안 서비스, Alert Logic - 채현주 보안기술본부장, Openbase :: AWS Sum...클라우드 환경에서의 SIEMLESS 통합 보안 서비스, Alert Logic - 채현주 보안기술본부장, Openbase :: AWS Sum...
클라우드 환경에서의 SIEMLESS 통합 보안 서비스, Alert Logic - 채현주 보안기술본부장, Openbase :: AWS Sum...
 
Penetration testing dont just leave it to chance
Penetration testing dont just leave it to chancePenetration testing dont just leave it to chance
Penetration testing dont just leave it to chance
 
How automation can help boost security
How automation can help boost securityHow automation can help boost security
How automation can help boost security
 
How Real Device Cloud Testing Ensures Exceptional Efficiency and Scalability ...
How Real Device Cloud Testing Ensures Exceptional Efficiency and Scalability ...How Real Device Cloud Testing Ensures Exceptional Efficiency and Scalability ...
How Real Device Cloud Testing Ensures Exceptional Efficiency and Scalability ...
 

More from TechWell

Failing and Recovering
Failing and RecoveringFailing and Recovering
Failing and Recovering
TechWell
 
Instill a DevOps Testing Culture in Your Team and Organization
Instill a DevOps Testing Culture in Your Team and Organization Instill a DevOps Testing Culture in Your Team and Organization
Instill a DevOps Testing Culture in Your Team and Organization
TechWell
 
Test Design for Fully Automated Build Architecture
Test Design for Fully Automated Build ArchitectureTest Design for Fully Automated Build Architecture
Test Design for Fully Automated Build Architecture
TechWell
 
System-Level Test Automation: Ensuring a Good Start
System-Level Test Automation: Ensuring a Good StartSystem-Level Test Automation: Ensuring a Good Start
System-Level Test Automation: Ensuring a Good Start
TechWell
 
Build Your Mobile App Quality and Test Strategy
Build Your Mobile App Quality and Test StrategyBuild Your Mobile App Quality and Test Strategy
Build Your Mobile App Quality and Test Strategy
TechWell
 
Testing Transformation: The Art and Science for Success
Testing Transformation: The Art and Science for SuccessTesting Transformation: The Art and Science for Success
Testing Transformation: The Art and Science for Success
TechWell
 
Implement BDD with Cucumber and SpecFlow
Implement BDD with Cucumber and SpecFlowImplement BDD with Cucumber and SpecFlow
Implement BDD with Cucumber and SpecFlow
TechWell
 
Develop WebDriver Automated Tests—and Keep Your Sanity
Develop WebDriver Automated Tests—and Keep Your SanityDevelop WebDriver Automated Tests—and Keep Your Sanity
Develop WebDriver Automated Tests—and Keep Your Sanity
TechWell
 
Ma 15
Ma 15Ma 15
Ma 15
TechWell
 
Eliminate Cloud Waste with a Holistic DevOps Strategy
Eliminate Cloud Waste with a Holistic DevOps StrategyEliminate Cloud Waste with a Holistic DevOps Strategy
Eliminate Cloud Waste with a Holistic DevOps Strategy
TechWell
 
Transform Test Organizations for the New World of DevOps
Transform Test Organizations for the New World of DevOpsTransform Test Organizations for the New World of DevOps
Transform Test Organizations for the New World of DevOps
TechWell
 
The Fourth Constraint in Project Delivery—Leadership
The Fourth Constraint in Project Delivery—LeadershipThe Fourth Constraint in Project Delivery—Leadership
The Fourth Constraint in Project Delivery—Leadership
TechWell
 
Resolve the Contradiction of Specialists within Agile Teams
Resolve the Contradiction of Specialists within Agile TeamsResolve the Contradiction of Specialists within Agile Teams
Resolve the Contradiction of Specialists within Agile Teams
TechWell
 
Pin the Tail on the Metric: A Field-Tested Agile Game
Pin the Tail on the Metric: A Field-Tested Agile GamePin the Tail on the Metric: A Field-Tested Agile Game
Pin the Tail on the Metric: A Field-Tested Agile Game
TechWell
 
Agile Performance Holarchy (APH)—A Model for Scaling Agile Teams
Agile Performance Holarchy (APH)—A Model for Scaling Agile TeamsAgile Performance Holarchy (APH)—A Model for Scaling Agile Teams
Agile Performance Holarchy (APH)—A Model for Scaling Agile Teams
TechWell
 
A Business-First Approach to DevOps Implementation
A Business-First Approach to DevOps ImplementationA Business-First Approach to DevOps Implementation
A Business-First Approach to DevOps Implementation
TechWell
 
Databases in a Continuous Integration/Delivery Process
Databases in a Continuous Integration/Delivery ProcessDatabases in a Continuous Integration/Delivery Process
Databases in a Continuous Integration/Delivery Process
TechWell
 
Mobile Testing: What—and What Not—to Automate
Mobile Testing: What—and What Not—to AutomateMobile Testing: What—and What Not—to Automate
Mobile Testing: What—and What Not—to Automate
TechWell
 
Cultural Intelligence: A Key Skill for Success
Cultural Intelligence: A Key Skill for SuccessCultural Intelligence: A Key Skill for Success
Cultural Intelligence: A Key Skill for Success
TechWell
 
Turn the Lights On: A Power Utility Company's Agile Transformation
Turn the Lights On: A Power Utility Company's Agile TransformationTurn the Lights On: A Power Utility Company's Agile Transformation
Turn the Lights On: A Power Utility Company's Agile Transformation
TechWell
 

More from TechWell (20)

Failing and Recovering
Failing and RecoveringFailing and Recovering
Failing and Recovering
 
Instill a DevOps Testing Culture in Your Team and Organization
Instill a DevOps Testing Culture in Your Team and Organization Instill a DevOps Testing Culture in Your Team and Organization
Instill a DevOps Testing Culture in Your Team and Organization
 
Test Design for Fully Automated Build Architecture
Test Design for Fully Automated Build ArchitectureTest Design for Fully Automated Build Architecture
Test Design for Fully Automated Build Architecture
 
System-Level Test Automation: Ensuring a Good Start
System-Level Test Automation: Ensuring a Good StartSystem-Level Test Automation: Ensuring a Good Start
System-Level Test Automation: Ensuring a Good Start
 
Build Your Mobile App Quality and Test Strategy
Build Your Mobile App Quality and Test StrategyBuild Your Mobile App Quality and Test Strategy
Build Your Mobile App Quality and Test Strategy
 
Testing Transformation: The Art and Science for Success
Testing Transformation: The Art and Science for SuccessTesting Transformation: The Art and Science for Success
Testing Transformation: The Art and Science for Success
 
Implement BDD with Cucumber and SpecFlow
Implement BDD with Cucumber and SpecFlowImplement BDD with Cucumber and SpecFlow
Implement BDD with Cucumber and SpecFlow
 
Develop WebDriver Automated Tests—and Keep Your Sanity
Develop WebDriver Automated Tests—and Keep Your SanityDevelop WebDriver Automated Tests—and Keep Your Sanity
Develop WebDriver Automated Tests—and Keep Your Sanity
 
Ma 15
Ma 15Ma 15
Ma 15
 
Eliminate Cloud Waste with a Holistic DevOps Strategy
Eliminate Cloud Waste with a Holistic DevOps StrategyEliminate Cloud Waste with a Holistic DevOps Strategy
Eliminate Cloud Waste with a Holistic DevOps Strategy
 
Transform Test Organizations for the New World of DevOps
Transform Test Organizations for the New World of DevOpsTransform Test Organizations for the New World of DevOps
Transform Test Organizations for the New World of DevOps
 
The Fourth Constraint in Project Delivery—Leadership
The Fourth Constraint in Project Delivery—LeadershipThe Fourth Constraint in Project Delivery—Leadership
The Fourth Constraint in Project Delivery—Leadership
 
Resolve the Contradiction of Specialists within Agile Teams
Resolve the Contradiction of Specialists within Agile TeamsResolve the Contradiction of Specialists within Agile Teams
Resolve the Contradiction of Specialists within Agile Teams
 
Pin the Tail on the Metric: A Field-Tested Agile Game
Pin the Tail on the Metric: A Field-Tested Agile GamePin the Tail on the Metric: A Field-Tested Agile Game
Pin the Tail on the Metric: A Field-Tested Agile Game
 
Agile Performance Holarchy (APH)—A Model for Scaling Agile Teams
Agile Performance Holarchy (APH)—A Model for Scaling Agile TeamsAgile Performance Holarchy (APH)—A Model for Scaling Agile Teams
Agile Performance Holarchy (APH)—A Model for Scaling Agile Teams
 
A Business-First Approach to DevOps Implementation
A Business-First Approach to DevOps ImplementationA Business-First Approach to DevOps Implementation
A Business-First Approach to DevOps Implementation
 
Databases in a Continuous Integration/Delivery Process
Databases in a Continuous Integration/Delivery ProcessDatabases in a Continuous Integration/Delivery Process
Databases in a Continuous Integration/Delivery Process
 
Mobile Testing: What—and What Not—to Automate
Mobile Testing: What—and What Not—to AutomateMobile Testing: What—and What Not—to Automate
Mobile Testing: What—and What Not—to Automate
 
Cultural Intelligence: A Key Skill for Success
Cultural Intelligence: A Key Skill for SuccessCultural Intelligence: A Key Skill for Success
Cultural Intelligence: A Key Skill for Success
 
Turn the Lights On: A Power Utility Company's Agile Transformation
Turn the Lights On: A Power Utility Company's Agile TransformationTurn the Lights On: A Power Utility Company's Agile Transformation
Turn the Lights On: A Power Utility Company's Agile Transformation
 

Recently uploaded

FIDO Alliance Osaka Seminar: Overview.pdf
FIDO Alliance Osaka Seminar: Overview.pdfFIDO Alliance Osaka Seminar: Overview.pdf
FIDO Alliance Osaka Seminar: Overview.pdf
FIDO Alliance
 
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
Product School
 
Accelerate your Kubernetes clusters with Varnish Caching
Accelerate your Kubernetes clusters with Varnish CachingAccelerate your Kubernetes clusters with Varnish Caching
Accelerate your Kubernetes clusters with Varnish Caching
Thijs Feryn
 
FIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdf
FIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdfFIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdf
FIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdf
FIDO Alliance
 
UiPath Test Automation using UiPath Test Suite series, part 4
UiPath Test Automation using UiPath Test Suite series, part 4UiPath Test Automation using UiPath Test Suite series, part 4
UiPath Test Automation using UiPath Test Suite series, part 4
DianaGray10
 
JMeter webinar - integration with InfluxDB and Grafana
JMeter webinar - integration with InfluxDB and GrafanaJMeter webinar - integration with InfluxDB and Grafana
JMeter webinar - integration with InfluxDB and Grafana
RTTS
 
Elevating Tactical DDD Patterns Through Object Calisthenics
Elevating Tactical DDD Patterns Through Object CalisthenicsElevating Tactical DDD Patterns Through Object Calisthenics
Elevating Tactical DDD Patterns Through Object Calisthenics
Dorra BARTAGUIZ
 
How world-class product teams are winning in the AI era by CEO and Founder, P...
How world-class product teams are winning in the AI era by CEO and Founder, P...How world-class product teams are winning in the AI era by CEO and Founder, P...
How world-class product teams are winning in the AI era by CEO and Founder, P...
Product School
 
Connector Corner: Automate dynamic content and events by pushing a button
Connector Corner: Automate dynamic content and events by pushing a buttonConnector Corner: Automate dynamic content and events by pushing a button
Connector Corner: Automate dynamic content and events by pushing a button
DianaGray10
 
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...
James Anderson
 
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdfSmart TV Buyer Insights Survey 2024 by 91mobiles.pdf
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf
91mobiles
 
To Graph or Not to Graph Knowledge Graph Architectures and LLMs
To Graph or Not to Graph Knowledge Graph Architectures and LLMsTo Graph or Not to Graph Knowledge Graph Architectures and LLMs
To Graph or Not to Graph Knowledge Graph Architectures and LLMs
Paul Groth
 
FIDO Alliance Osaka Seminar: Passkeys at Amazon.pdf
FIDO Alliance Osaka Seminar: Passkeys at Amazon.pdfFIDO Alliance Osaka Seminar: Passkeys at Amazon.pdf
FIDO Alliance Osaka Seminar: Passkeys at Amazon.pdf
FIDO Alliance
 
From Siloed Products to Connected Ecosystem: Building a Sustainable and Scala...
From Siloed Products to Connected Ecosystem: Building a Sustainable and Scala...From Siloed Products to Connected Ecosystem: Building a Sustainable and Scala...
From Siloed Products to Connected Ecosystem: Building a Sustainable and Scala...
Product School
 
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
Albert Hoitingh
 
AI for Every Business: Unlocking Your Product's Universal Potential by VP of ...
AI for Every Business: Unlocking Your Product's Universal Potential by VP of ...AI for Every Business: Unlocking Your Product's Universal Potential by VP of ...
AI for Every Business: Unlocking Your Product's Universal Potential by VP of ...
Product School
 
Securing your Kubernetes cluster_ a step-by-step guide to success !
Securing your Kubernetes cluster_ a step-by-step guide to success !Securing your Kubernetes cluster_ a step-by-step guide to success !
Securing your Kubernetes cluster_ a step-by-step guide to success !
KatiaHIMEUR1
 
De-mystifying Zero to One: Design Informed Techniques for Greenfield Innovati...
De-mystifying Zero to One: Design Informed Techniques for Greenfield Innovati...De-mystifying Zero to One: Design Informed Techniques for Greenfield Innovati...
De-mystifying Zero to One: Design Informed Techniques for Greenfield Innovati...
Product School
 
Designing Great Products: The Power of Design and Leadership by Chief Designe...
Designing Great Products: The Power of Design and Leadership by Chief Designe...Designing Great Products: The Power of Design and Leadership by Chief Designe...
Designing Great Products: The Power of Design and Leadership by Chief Designe...
Product School
 
The Art of the Pitch: WordPress Relationships and Sales
The Art of the Pitch: WordPress Relationships and SalesThe Art of the Pitch: WordPress Relationships and Sales
The Art of the Pitch: WordPress Relationships and Sales
Laura Byrne
 

Recently uploaded (20)

FIDO Alliance Osaka Seminar: Overview.pdf
FIDO Alliance Osaka Seminar: Overview.pdfFIDO Alliance Osaka Seminar: Overview.pdf
FIDO Alliance Osaka Seminar: Overview.pdf
 
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
From Daily Decisions to Bottom Line: Connecting Product Work to Revenue by VP...
 
Accelerate your Kubernetes clusters with Varnish Caching
Accelerate your Kubernetes clusters with Varnish CachingAccelerate your Kubernetes clusters with Varnish Caching
Accelerate your Kubernetes clusters with Varnish Caching
 
FIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdf
FIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdfFIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdf
FIDO Alliance Osaka Seminar: The WebAuthn API and Discoverable Credentials.pdf
 
UiPath Test Automation using UiPath Test Suite series, part 4
UiPath Test Automation using UiPath Test Suite series, part 4UiPath Test Automation using UiPath Test Suite series, part 4
UiPath Test Automation using UiPath Test Suite series, part 4
 
JMeter webinar - integration with InfluxDB and Grafana
JMeter webinar - integration with InfluxDB and GrafanaJMeter webinar - integration with InfluxDB and Grafana
JMeter webinar - integration with InfluxDB and Grafana
 
Elevating Tactical DDD Patterns Through Object Calisthenics
Elevating Tactical DDD Patterns Through Object CalisthenicsElevating Tactical DDD Patterns Through Object Calisthenics
Elevating Tactical DDD Patterns Through Object Calisthenics
 
How world-class product teams are winning in the AI era by CEO and Founder, P...
How world-class product teams are winning in the AI era by CEO and Founder, P...How world-class product teams are winning in the AI era by CEO and Founder, P...
How world-class product teams are winning in the AI era by CEO and Founder, P...
 
Connector Corner: Automate dynamic content and events by pushing a button
Connector Corner: Automate dynamic content and events by pushing a buttonConnector Corner: Automate dynamic content and events by pushing a button
Connector Corner: Automate dynamic content and events by pushing a button
 
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...
GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using Deplo...
 
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdfSmart TV Buyer Insights Survey 2024 by 91mobiles.pdf
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf
 
To Graph or Not to Graph Knowledge Graph Architectures and LLMs
To Graph or Not to Graph Knowledge Graph Architectures and LLMsTo Graph or Not to Graph Knowledge Graph Architectures and LLMs
To Graph or Not to Graph Knowledge Graph Architectures and LLMs
 
FIDO Alliance Osaka Seminar: Passkeys at Amazon.pdf
FIDO Alliance Osaka Seminar: Passkeys at Amazon.pdfFIDO Alliance Osaka Seminar: Passkeys at Amazon.pdf
FIDO Alliance Osaka Seminar: Passkeys at Amazon.pdf
 
From Siloed Products to Connected Ecosystem: Building a Sustainable and Scala...
From Siloed Products to Connected Ecosystem: Building a Sustainable and Scala...From Siloed Products to Connected Ecosystem: Building a Sustainable and Scala...
From Siloed Products to Connected Ecosystem: Building a Sustainable and Scala...
 
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024
 
AI for Every Business: Unlocking Your Product's Universal Potential by VP of ...
AI for Every Business: Unlocking Your Product's Universal Potential by VP of ...AI for Every Business: Unlocking Your Product's Universal Potential by VP of ...
AI for Every Business: Unlocking Your Product's Universal Potential by VP of ...
 
Securing your Kubernetes cluster_ a step-by-step guide to success !
Securing your Kubernetes cluster_ a step-by-step guide to success !Securing your Kubernetes cluster_ a step-by-step guide to success !
Securing your Kubernetes cluster_ a step-by-step guide to success !
 
De-mystifying Zero to One: Design Informed Techniques for Greenfield Innovati...
De-mystifying Zero to One: Design Informed Techniques for Greenfield Innovati...De-mystifying Zero to One: Design Informed Techniques for Greenfield Innovati...
De-mystifying Zero to One: Design Informed Techniques for Greenfield Innovati...
 
Designing Great Products: The Power of Design and Leadership by Chief Designe...
Designing Great Products: The Power of Design and Leadership by Chief Designe...Designing Great Products: The Power of Design and Leadership by Chief Designe...
Designing Great Products: The Power of Design and Leadership by Chief Designe...
 
The Art of the Pitch: WordPress Relationships and Sales
The Art of the Pitch: WordPress Relationships and SalesThe Art of the Pitch: WordPress Relationships and Sales
The Art of the Pitch: WordPress Relationships and Sales
 

Better Security Testing: Using the Cloud and Continuous Delivery

  • 1. T17 Security Testing 5/2/2013 1:30:00 PM Better Security Testing: Using the Cloud and Continuous Delivery Presented by: Gene Gotimer Coveros, Inc. Brought to you by: 340 Corporate Way, Suite 300, Orange Park, FL 32073 888-268-8770 ∙ 904-278-0524 ∙ sqeinfo@sqe.com ∙ www.sqe.com
  • 2. Gene Gotimer Gene Gotimer is a senior architect at Coveros, Inc., a consulting company that uses agile methods to accelerate the delivery of secure, reliable software. Gene is an experienced software developer who focuses on continuous integration, static code analysis, automation, and any tool he can find to do his work for him. For the past few years, he has been on a team that is bringing a continuous delivery process into the US Department of Defense, showing that higher quality software can be delivered quicker and with more security by using agile techniques.
  • 3. 4/16/2013 Gene Gotimer, Senior Architect gene.gotimer@coveros.com © Copyright 2013 Coveros, Inc. All rights reserved. 1 About Coveros Coveros helps organizations accelerate the delivery of business value through secure, reliable software © Copyright 2013 Coveros, Inc. All rights reserved. 2 1
  • 4. 4/16/2013 Security Testing Late in the cycle Issues are not remediated Needs ROI: lower cost, better results, or both © Copyright 2013 Coveros, Inc. All rights reserved. 3 Security Testing Consider open-source and free tools Opportunities in Continuous Delivery and Cloud Identify low effort opportunities using free and open-source tools © Copyright 2013 Coveros, Inc. All rights reserved. 4 2
  • 5. 4/16/2013 Continuous Integration Merge work frequently Code commits to source control Unit tests run automatically No long integration cycle at the end Fix code when we find problems Build-Test-Commit cycle = rapid feedback © Copyright 2013 Coveros, Inc. All rights reserved. 5 Continuous Delivery Every build potentially releasable Release is a business decision Extrapolation of Continuous Integration – Deploys – Functional tests – Load and performance tests – Security tests Build-Test-Commit-Deploy-Test-Release cycle © Copyright 2013 Coveros, Inc. All rights reserved. 6 3
  • 6. 4/16/2013 Cloud Computing Can’t wait for long procurement Public or Private clouds Works well with Continuous Delivery – Easy to deploy – New environments whenever © Copyright 2013 Coveros, Inc. All rights reserved. 7 Maturity Model for Security Testing Level 0: No Security Testing Level 1: Unit Testing and Static Analysis Level 2: Automated Deploys and Functional Testing Level 3: Automated Configuration Management Level 4: Cloud Deployments Level 5: Continuous Delivery © Copyright 2013 Coveros, Inc. All rights reserved. 8 4
  • 7. 4/16/2013 Maturity Model for Security Testing Level 0: No Security Testing Level 1: Unit Testing and Static Analysis Level 2: Automated Deploys and Functional Testing Level 3: Automated Configuration Management Level 4: Cloud Deployments Level 5: Continuous Delivery © Copyright 2013 Coveros, Inc. All rights reserved. 9 Maturity Model for Security Testing Level 0: No Security Testing Level 1: Unit Testing and Static Analysis Level 2: Automated Deploys and Functional Testing Level 3: Automated Configuration Management Level 4: Cloud Deployments Level 5: Continuous Delivery © Copyright 2013 Coveros, Inc. All rights reserved. 10 5
  • 8. 4/16/2013 Level 1: Unit Testing and Static Analysis Unit Tests: – Confidence to make changes – Error handling – General logic errors – Bounds checking – Edge conditions © Copyright 2013 Coveros, Inc. All rights reserved. 11 © Copyright 2013 Coveros, Inc. All rights reserved. 12 Level 1: Unit Testing and Static Analysis Static Analysis: – Common errors – Unused variables – SQL injection – Cross-Site Scripting (XSS) – Hard-coded passwords 6
  • 9. 4/16/2013 Level 1: Unit Testing and Static Analysis Unit testing: JUnit for Java NUnit for .Net PyUnit for Python PHPUnit for PHP Static Analysis: Sonar for many languages PMD for Java FindBugs for Java PHPMD for PHP FxCop for .Net PyChecker for Python pylint for Python © Copyright 2013 Coveros, Inc. All rights reserved. 13 Maturity Model for Security Testing Level 0: No Security Testing Level 1: Unit Testing and Static Analysis Level 2: Automated Deploys and Functional Testing Level 3: Automated Configuration Management Level 4: Cloud Deployments Level 5: Continuous Delivery © Copyright 2013 Coveros, Inc. All rights reserved. 14 7
  • 10. 4/16/2013 Level 2: Automated Deploys and Functional Testing Automated Deploys: – Frequent security scans – Rapid feedback – Web application scanners: w3af wapiti Skipfish – Start basic, add tuning © Copyright 2013 Coveros, Inc. All rights reserved. 15 Level 2: Automated Deploys and Functional Testing Functional Testing: – Access control – Data protection – Web Application testing: Selenium © Copyright 2013 Coveros, Inc. All rights reserved. 16 8
  • 11. 4/16/2013 Level 2: Automated Deploys and Functional Testing Proxies: – Better coverage – XSS and Cross-Site Request Forgery (XSRF) – Data leakage – URLs for logs to augment spidering – Web application proxies: OWASP Zed Attack Proxy (ZAP) Project OWASP WebScarab Ratproxy © Copyright 2013 Coveros, Inc. All rights reserved. 17 Maturity Model for Security Testing Level 0: No Security Testing Level 1: Unit Testing and Static Analysis Level 2: Automated Deploys and Functional Testing Level 3: Automated Configuration Management Level 4: Cloud Deployments Level 5: Continuous Delivery © Copyright 2013 Coveros, Inc. All rights reserved. 18 9
  • 12. 4/16/2013 Level 3: Automated Configuration Management Deployment/Configuration: Puppet Chef Provisioning: Cobbler Kickstart Windows Deployment Services Completely new systems or build on templates Repeatable configuration management © Copyright 2013 Coveros, Inc. All rights reserved. 19 Level 3: Automated Configuration Management Complete system scans OpenVAS Nmap Nikto2 © Copyright 2013 Coveros, Inc. All rights reserved. 20 10
  • 13. 4/16/2013 Maturity Model for Security Testing Level 0: No Security Testing Level 1: Unit Testing and Static Analysis Level 2: Automated Deploys and Functional Testing Level 3: Automated Configuration Management Level 4: Cloud Deployments Level 5: Continuous Delivery © Copyright 2013 Coveros, Inc. All rights reserved. 21 Level 4: Cloud Deployments On-demand environments – Long running scans in parallel – Production-sized machines, even temporarily – Failover and high-availability Multiple client systems in parallel – Race conditions – Multi-user interactions © Copyright 2013 Coveros, Inc. All rights reserved. 22 11
  • 14. 4/16/2013 Level 4: Cloud Deployments Web performance testing frameworks: Apache Jmeter: Java-based UI • HTTP, HTTPS, SOAP, JDBC, LDAP, JMS, SMTP, POP, IMAP ab, ApacheBench: command-line The Grinder: Jython and Clojure Gatling: Scala © Copyright 2013 Coveros, Inc. All rights reserved. 23 Maturity Model for Security Testing Level 0: No Security Testing Level 1: Unit Testing and Static Analysis Level 2: Automated Deploys and Functional Testing Level 3: Automated Configuration Management Level 4: Cloud Deployments Level 5: Continuous Delivery © Copyright 2013 Coveros, Inc. All rights reserved. 24 12
  • 15. 4/16/2013 Level 5: Continuous Delivery Release ready for production Continuous deployment High levels of automation Dashboards – Custom development © Copyright 2013 Coveros, Inc. All rights reserved. 25 Personal Experience Agile development grew into Continuous Delivery Automated deploys with Puppet Selenium functional tests JMeter performance tests © Copyright 2013 Coveros, Inc. All rights reserved. 26 13
  • 16. 4/16/2013 Personal Experience Security testing lagged Excuses: – The “official” tool is expensive. – It would take a lot of time to acquire and then to configure it. – We don’t have time. – It isn’t our responsibility. – The security team wouldn’t accept our scans anyway. Open-source tools Focus on security, not compliance Limited time © Copyright 2013 Coveros, Inc. All rights reserved. 27 © Copyright 2013 Coveros, Inc. All rights reserved. 28 Personal Experience Web application scans with w3af Vulnerability assessments with OpenVAS Security standards checks with Openscap Initial implementation ~ a day each No more freebies 14
  • 17. 4/16/2013 Conclusion Earlier security testing – Less likely to skip – More likely to remediate Open-source tools Other testing as foundation Gradually add more security tests Continuous Delivery and Cloud Computing give security testing opportunities © Copyright 2013 Coveros, Inc. All rights reserved. 29 © Copyright 2013 Coveros, Inc. All rights reserved. 30 Questions? 15
  • 18. Better Security Testing Using the Cloud and Continuous Delivery Gene Gotimer Coveros, Inc. Security testing is often put off as one of the last tasks of the development cycle. So when the security scans or reviews find vulnerabilities, businesses can be put in the position of remediating the security issues appropriately and delaying a release or keeping a release on schedule and accepting the risks. Those risks are not always clearly understood and almost never have a clear dollar figure associated with them. Without really knowing what they are getting into, security remediation may be dropped and the security testing treated as a checkbox that “we ran the security test tool” with no action being taken as a result. It is easy to see how security testing can become an afterthought or a second-class citizen during the development process. It becomes a question of return on investment (ROI). To make a stronger case for additional security testing we either have to increase the return or decrease the investment. There is good news. Open-source and free security testing tools are growing in popularity and capability. A development team can quickly (and, if needed, quietly) add security testing tools to their process, without procuring an expensive security tool. That reduces the cost of the initial investment and may eliminate some barriers to entry. And it turns out that Cloud initiatives and efforts towards Continuous Delivery (CD) not only have some great benefits of their own, but can also provide some opportunities to get security testing in place without a large outlay of resources. For a team that is trying to increase their security testing as cheaply as possible, there are plenty of chances to add it to their process almost for free. Those will be the focus of my discussion: low effort opportunities to integrate security testing into the development process, and the free and open-source tools that can make it practical. While I will focus on free and open-source tools, commercial tools can be better and easier to use. A more mature security testing practice may choose to use the commercial tool instead. Commercial tools may already be available in your organization, which can ease adoption by being already paid for, by being easier to use, by being more capable, and especially by having some people in your organization that can help you use the tool and interpret the results. Continuous Integration Continuous integration (CI) is the practice of merging the work from multiple developers frequently, often multiple times per day. It almost always involves frequent code commits to a source control system and running unit tests on each and every commit. The primary benefit is that there is no long 1
  • 19. cycle of integration at the end of the development cycle with developers scrambling to make all our code work together. Plus, as the unit tests and the integration efforts find problems, we make adjustments to our code while it is fresh in the developer’s minds. Developers get into a build-testcommit cycle which gives us rapid feedback and makes working, unit-tested code available to the rest of the team on a continuous basis. Continuous Delivery Continuous delivery is a software development process that aims to have every build releasable to production. It may not be released, but everyone involved will be able to make an informed business decision to release that software without having to guess whether or not it will work. Continuous delivery can be viewed as the logical extrapolation of continuous integration. After running the normal unit tests on the code, we frequently deploy code and run other tests, such as functional tests, load and performance tests, and even security tests. By extending the CI concept of build-testcommit to be build-test-commit-deploy-test-release, we can extend the rapid feedback cycle all the way out to production releases, or at least to the point of releasable software. And instead of just having unit-tested code available to the other developers, now we have production-ready code available to the business. Enabling continuous delivery means adding automation to deploys, so that deploys can happen without a lot of effort. If it is expensive in terms of time and effort to deploy, it won’t be done often. And if it isn’t automated, it won’t be repeatable and consistent. Not only do deploys to our test environments become non-events, but we know when we push into production that the deploy process will work the same way. After all, the deploy process has been tested just as often as the code has. Cloud Computing Cloud computing has brought a new economy to acquiring and provisioning computing resources. Along with that, the cloud has brought a new wave of tools to make configuration management and software deployment capable of exploiting that new found speed and low costs. Because we are deploying on a rapid schedule, we can’t wait for the normal weeks-to-months long procurement and installation cycles to get hardware ready for us to deploy to. With cloud computing, the procurement cycle can be minutes long. And the investment per project is usually lower, too. If we use a public cloud like Amazon, cloud services are always available for ordering. Virtually any amount of computing power can be ordered whenever we need it. Private cloud computing resources are often pooled, so when we are done using them the resources can be returned to the pool for other teams to use. Cloud computing has a symbiotic relationship with continuous delivery. Deploys are easy because they are automated, so we have less of a barrier to standing up new environments. And establishing new 2
  • 20. environments in the cloud is easy, so we can stand one up from scratch whenever it would be convenient to have another instance of the application deployed. Maturity Model for Security Testing To grow a security testing practice, we need to first take stock of where we stand now. Then we need to have some path to follow, milestones to shoot for, and some way to measure if we are making improvements or not. One way to measure our current state and chart our growth is a maturity model. We’ll start by setting the scale. The levels might be good for comparing the maturity of security testing between two different projects, but they are really just intended as an example of milestones to aim for. Each level represents an opportunity to introduce new security tests and security testing tools into the process. The progression ranges from introducing security testing to an established practice and onto advancing and refining your security testing capabilities. • • • • • • Level 0: No Security Testing Level 1: Unit Testing and Static Analysis Level 2: Automated Deploys and Functional Testing Level 3: Automated Configuration Management Level 4: Cloud Deployments Level 5: Continuous Delivery These levels aren’t equally spaced in time or effort to achieve them. Going from nothing to unit tests and static analysis is much easier than going from automated configuration management to cloud deployments. In general, the more mature the practice, the more effort it will require to incorporate the next practice. The early ones are the types of testing we can add almost for free, while the later practices require a lot of discipline and a committed effort. Largely for this reason, not every project will benefit from working towards the ultimate level. It might be sufficient to unit test and do static analysis on an internal utility with a limited lifespan and no sensitive data or access, while an online ordering system available to the public certainly needs more security attention. What constitutes “enough” security testing has to be determined for each project. Level 0: No Security Testing The initial state is no security testing. We’ll score that as a zero. Unfortunately, far too many projects start and end here. The good news is that if we start here, even the slightest bit of improvement is a win. Level 1: Unit Testing and Static Analysis The next step, barely doing any security testing, is very easy to integrate into our development process: simply add unit testing and static analysis. You might not normally file those under security tests, but they are a good foot in the door and if you are doing CI you probably have these already. 3
  • 21. Perhaps the biggest advantage of having good unit tests is the confidence that we can make changes to an application safely, without making unintended changes to behavior. That decreases the risks involved with any code changes, including security remediation, even late in the development cycle. This makes unit testing a critical practice as the foundation for any development. Through normal efforts in unit testing, most developers will start testing edge cases and failure cases. For example, • • • • What happens if we have no items in the list we are iterating through? What happens when we expect 5 items but only get 4? How do we handle a file not found when we try to read a configuration file? What if the file is found but not in the correct format? Poor handling of these types of errors can lead to some common type of security vulnerabilities: error handling, general logic errors, bounds checking, etc. Unit testing is well-suited to identifying some of these error types since the units are tested independently. Fewer assumptions about the input and program state are made, so the units are able to better stand on their own. As a result, it can be easier to test each unit more thoroughly for undesirable or unexpected conditions. Adding a code coverage tool can help us identify edge conditions and testing opportunities that we missed initially. Static analysis tools look at source code or compiled code, looking for common errors, unused variables, style and formatting variations, and similar items. Like unit tests, static analysis tools can identify some potential security problems: • • • • Are inputs validated? Are outputs escaped? Is the source code hard to understand, and therefore easy for other developers to misuse? Is there a lot of duplicated source code? If we fix a bug once will the same problem crop up in other places? Most modern languages have a selection of open-source static analysis tools that can scan source code looking for predictable problems. SQL injection, Cross-Site Scripting (XSS), and hard-coded passwords are common vulnerabilities that can often be detected by static code analysis. With a CI practice, it is easy to configure unit testing and static code analysis to run on every commit or at least every night. We can make it part of a project’s boilerplate build scripts and/or even enable it in our CI engine with little more than the click of a configuration checkbox. Just adding unit testing or static analysis isn’t a comprehensive security testing process, but it is easy to get started and is far better than nothing. And we need to have these anyway. Here are some suggestions for some free and/or open-source tools to get started: 4
  • 22. • • Unit testing:     Static Analysis:        JUnit for Java, http://junit.org NUnit for .Net, http://www.nunit.org PyUnit for Python, http://pyunit.sourceforge.net PHPUnit for PHP, http://www.phpunit.de Sonar for many languages, http://www.sonarsource.org PMD for Java, http://pmd.sourceforge.net FindBugs for Java, http://findbugs.sourceforge.net PHPMD for PHP, http://phpmd.org FxCop for .Net, http://msdn.microsoft.com/en-us/library/bb429476.aspx PyChecker for Python, http://pychecker.sourceforge.net pylint for Python, http://www.pylint.org Level 2: Automated Deploys and Functional Testing Automated deploys are the first step most teams think of when they start working towards continuous delivery. Automated deploys also open up some opportunities for more focused security testing. The most obvious opportunity is just being able to scan the deployed application on a frequent basis. If we can deploy automatically, then we can kick off security tests after we deploy and get a scan early in the development cycle. We can investigate and remediate vulnerabilities we find before it is too late to address them. Even better, if we can trigger a deploy and scan using our CI engine, then developers can get same-day or next-day feedback that shows that they may have introduced a security issue. They can fix problems while the code is still fresh on their minds. The easiest way to start scanning an automated deploy is with black-box tools that can just be pointed at the deployed application and need little-to-no configuration initially. Some examples for web applications include: • • • w3af, http://w3af.org wapiti, http://wapiti.sourceforge.net Skipfish, http://code.google.com/p/skipfish/ While these tools can (and should) eventually be tuned to better suit our application, even the most basic scans can provide a wealth of information. Simple tuning can usually limit runtimes to be short enough to fit the situation. For example, every hour we could run a quick, superficial scan that takes 10 minutes and then overnight we could run a more detailed scan. Automated deployments also ease automated functional testing. In addition to the normal user behavior tests, we can use functional tests to test access controls and data protection. User roles can be very thoroughly tested using automated functional tests, especially when doing negative testing. For 5
  • 23. example, a user should be able to see their account information, but not someone else’s. Users with one role should be able to access certain functionality, but not other functionality. The most popular open source functional test framework for web applications is Selenium (http://seleniumhq.org), although there are plenty of good alternatives. There are also many good options for applications that aren’t web-based or browser-based, such as web services. Having those tests automated means they can be run frequently, and they become a great shield against regression bugs and unintended data leakage. Like unit tests, the strongest advantage of automated functional tests is that changes can be made to individual features without introducing unwanted behavior changes. If we enable a role to view a new aggregate report, did those users also get the ability to view someone else data? If we explicitly add the ability for a role to see another user’s data, are they still prohibited from making changes to it? If we combine the automated functional tests with security scanning we get some very good insight into possible vulnerabilities. Running the functional tests through a proxy can uncover XSS and Cross-Site Request Forgery (XSRF) issues that a typical web scanner could not reach without login credentials or complex combinations of actions, for example. Proxies can also help find unintended external data leakage, such as a finding that a third-party library uses a public web service to generate charts. Collecting URLs from web access logs that were accessed during functional tests can be a great addition to spidering targets for web application scanners. Free web application proxies include: • • • OWASP Zed Attack Proxy (ZAP) Project, https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project OWASP WebScarab, https://www.owasp.org/index.php/Category:OWASP_WebScarab_Project Ratproxy, http://code.google.com/p/ratproxy/ Level 3: Automated Configuration Management Configuration management means different things to different people, but I am referring to being able to determine and recreate the state of a computer system: OS, configuration files and settings, package versions, dependency versions, etc. Frameworks such as Puppet (https://puppetlabs.com/puppet/puppet-open-source/) and Chef (http://www.opscode.com/chef/) are gaining a lot of traction for handling automated configuration management functions. They allow package versions, file permissions and ownership, and network services to be specified and controlled in code, rather than a list of manual steps a system administrator must remember to follow upon installation. Puppet and Chef can be used alongside tools such as Cobbler (http://cobbler.github.com/), Kickstart (http://fedoraproject.org/wiki/Anaconda/Kickstart), or Windows Deployment Services (http://msdn.microsoft.com/en-us/library/aa967394.aspx) to stand up a system from “bare metal”. Or 6
  • 24. they can be used in conjunction with a “Gold Disk” or other standardized OS installs to completely recreate a production-like environment and system laydown. From a security point of view, the configuration management itself is the biggest draw. Being able to review and specify a system configuration via code and knowing that it represents the actual system state rather than the requested system state is invaluable during security audits. And the ability to recreate an environment has tremendous forensic value when troubleshooting a security incident, not to mention simply being able to reliably recreate production bugs in non-production environments. Another advantage is that we can baseline (return to a known state) a complete system easily. That means that we can run a security scan on a cleanly installed system, and the entire system can be analyzed. Scanners like OpenVAS (http://www.openvas.org/), an open-source Nessus fork, Nmap (http://nmap.org/), and Nikto2 (http://cirt.net/nikto2) can be used against a system to scan for vulnerabilities via open ports and exposed services. We can schedule these tools to run regularly or scripted to run from a CI engine. Rather than wait for a security expert to schedule a scan of our application on a pre-production system just before release, we can scan the system every day so that we know the results and can remediate issues during the development cycle. Level 4: Cloud Deployment Deploying our application in the cloud allows environments to be stood up without much time, effort, or cost. Since we’ve already automated the deployment and the OS and system installation, now standing up a new environment from nothing can be effortless, even without provisioned hardware. That in turn means we can stand up an environment whenever we need it and only keep it operating while it is in use. More projects can share fewer resources since they won’t all need the resources at the same time. We can run long running scans, such as deep fuzzing scans, against a newly provisioned, dedicated environment while other development efforts continue in other environments in parallel. Also, we can execute resource intensive tests with adequate resources even if those resources cannot be reserved indefinitely. Performance, load, and stress tests can be run on “production-sized” machines rather than possibly undersized development systems. That can help better identify limits and reduce the risks of denial of service attacks. Failover and high-availability systems often get tested once prior to the initial production release, and then never tested again, only because it was too expensive to have an entire extra set of redundant systems stood up in a test environment. Some tests can benefit from the use of multiple client systems as well. Rather than running a many hours of functional tests overnight and having a one-day lag between code commit and test results, we can use cloud resources to stand up multiple client systems to run the functional tests in parallel. Not only can we run the tests more often since they take less elapsed time, but we’ll be better able to identify RACE conditions and multi-user interactions. Open-source performance testing frameworks for web-based applications include: 7
  • 25. • • • • Apache JMeter (http://jmeter.apache.org), which builds tests from a Java-based UI and can test HTTP, HTTPS, SOAP, JDBC, LDAP, JMS, SMTP, POP, and IMAP, among other protocols ab, ApacheBench (http://httpd.apache.org/docs/2.4/programs/ab.html), for command-line driven performance tests The Grinder (http://grinder.sourceforge.net), for load testing with tests written in Jython and Clojure Gatling (http://gatling-tool.org), for stress testing with tests written in Scala Level 5: Continuous Delivery Continuous delivery means being able to delivery software at any time. It takes releasing software from what had been a lengthy and often risky development process to an automated process that ensure the timing of a release is a purely business decision. It can range in practice from having a release always ready to go should the stakeholder want to promote it to production, to continuous deployment where the software is tested thoroughly enough that stakeholders are confident that it can be promoted automatically, without any human decision points, whenever all automated testing reaches a “good enough” threshold. This stage requires a very high level of automation, so that we have enough confidence in all testing (functional, regression, performance, and security testing) to allow unattended, automated releases. Most software, and certainly most organizations, will never reach this level of trust in automated testing, but it is a valuable goal. Along with the automation itself, dashboards are important to display the results of all the various builds and tests through the process. The more automation and testing that is involved, the more information that has to be processed, and the more important dashboards become. The proliferation of environments makes it critical for us to be able to quickly determine what the configuration of each environment is, what packages are installed, what tests have been performed, and what the results of those tests were. Unfortunately, there aren’t any ready-to-use open-source dashboards for a continuous delivery process, which makes sense since the process and tools can vary significantly from team to team and project to project. We will have to develop these dashboards as they are needed. Personal Experience My current project is a large integration and customization project for the Department of Defense (DoD). As part of our mission, our team was tasked to introduce an agile development process and demonstrate how it could be used on a DoD project. That eventually became an effort to work towards a Continuous Delivery process, and to show if and how it would work in the DoD environment. We’ve made great progress. Over the last year we have added deploys that are almost entirely automated using Puppet, although a few manual steps still remain. We have developed a suite of functional tests to cover our entire system. The system is web based, and we have chosen Selenium for 8
  • 26. our functional tests. We have just recently added JMeter testing to measure performance, really focused on watching the trends as we make releases. I.e., have we made the system noticeably faster/slower? One item we had not addressed until well into the project was security testing. We had done it a few times manually, but another part of the organization was responsible for the security scanning, so we didn’t build it into our process. If that sounds like a weak justification, it is. We just kept making excuses, such as: • • • • • The “official” tool is expensive. It would take a lot of time to acquire and then to configure it. We don’t have time. It isn’t our responsibility. The security team wouldn’t accept our scans anyway. While there is a grain of truth to each of those, we finally gave it some serious thought and realized that we already had the infrastructure and process to support some security testing, and could start doing a lot more with very little effort. We decided we would focus on open-source tools that paralleled what the security team would eventually use. The more testing we did up front, the less likely we were to be surprised by findings at the end of the cycle. Focusing on improving the security was more important for our development team than worrying if we could satisfy compliance requirements by running particular tools. But since security truly was the responsibility of another team, we did not have any significant time to implement our testing. We use w3af to do web application scanning. Our application relies on client-side certificates for login, so we had to make some slight customizations to w3af to deal with passing a certificate in. Fortunately, w3af is open source and written in Python, and it was easy to add the required support with just a few lines of code. We can run w3af from our CI engine, Jenkins, but don’t often because we haven’t come up with a convenient way to display the results. Since a manual inspection of the scan results is still required we don’t execute the w3af scans continuously. We are working on better reporting so we can quickly see what changes in the scans were made with the recent changes to the code. We set up OpenVAS to do remote scans and vulnerability assessments. The scans run each weekend against our test systems. Ten servers are scanned in parallel; the scans are completed in less than two hours. We could scan more often, but the systems themselves don’t change open ports and installed packages often enough to warrant it. If needed, we can start the scans on demand. OpenVAS maintains a history of the scans and can track issues we’ve identified as false positives. It also shows changes and overall trends in the number of vulnerabilities. We added Openscap (http://www.open-scap.org) as part of our CI process. It runs a series of automated checks against our systems to determine compliance with a set of security standards, which in our case are mandated. Security Content Automation Protocol (SCAP) has a fair number of checks that must be 9
  • 27. manually performed as well, but at least running the automated checks makes our compliance efforts easier. Most importantly, we can see when a change to our system or to our application introduces or fixes any security vulnerabilities. Each of these security scans was initially implemented in a day or so, using down time in between other assigned tasks. We added them to the process because they were open source, easy to introduce, and did not slow down or complicate our existing process. Also, it was easy to interpret the results, so we could act upon the results so that the scans had real value in our process. If you can’t understand the findings, you can’t act on them. On our scale of maturity, we’ve pushed through automated configuration management and are beginning to do more cloud deployments, but our security testing is lagging a little behind that. We are just starting to take advantage of the cloud for performance testing and slower running security scans. On the other hand, we have a good selection of scans going on that help us ensure that our systems and our application are more secure and more likely to meet compliance rules. Also, we find out quickly if changes we make to the system configuration or to the application introduce any new security issues. It seems like we’ve exhausted our “free” opportunities to increase the security testing. Most of what we’ll add in the future will require some real focus and effort. But the groundwork we have laid is already showing value, so garnering support for those larger efforts should be easier. Conclusion Doing security testing earlier in the development cycle means it is less likely to be dropped and more likely we will remediate the problems that we find. By using open-source tools and identifying opportunities to add security testing into our current processes, we can reduce the cost of adopting security testing. Other, non-security testing can lay the foundation for security tests and safe remediation. Gradually adding security testing, even little pieces of it, can quickly add value. Whether you already have continuous delivery and cloud initiatives underway and are piggybacking on them, or are using additional security testing potential as an argument to adopt them, the continuous delivery process and cloud computing efforts give ample opportunities to add security testing without much effort. About the Author Gene Gotimer is a senior architect at Coveros, Inc., a consulting company that uses agile methods to accelerate the delivery of secure, reliable software. Gene is an experienced software developer who focuses on continuous integration, static code analysis, automation, and any tool he can get to do his work for him. For the last few years he has been on a team that is bringing a continuous delivery process into the US Department of Defense, showing other projects that software can be delivered quicker with more security and higher quality by using agile techniques. 10