devopsy.kinsta.cloud

Tag: security

Automated Security Testing in a Continuous Delivery Pipeline
Automated unit, integration and acceptance tests are essential quality controls in running a reliable continuous integration or continuous delivery pipeline. Too often, security tests are left out of this process because of the erroneous belief that security testing is solely the domain of leather-jacket-wearing security experts.

Security testing does not need special treatment

We’ve made great strides automating many repetitive quality testing tasks and we can use the same approach to automating security tests. There will always be a need for intelligent human testing both for security and quality, but that doesn’t mean that all security testing must be manually driven. A large proportion of security tests are essentially checks that known weaknesses have not been introduced and these lend themselves superbly to automation. In fact, using a human to perform these types of checks is a terrible waste of resources.

From an automation point of view, security tests can be categorised as follows:
1. Functional Security Tests.
  These are essentially the same as automated acceptance tests, but targeted at verifying that security features such as
  authentication and logout, work as expected. They can mostly be automated using existing acceptance testing browser automation tools like Selenium/WebDriver.
2. Specific non-functional tests against known weaknesses.
  Includes testing known weaknesses and mis-configurations such as lack of the HttpOnly flag on session cookies, or use of known weak SSL suites and ciphers. These are particularly well suited for automation because the weaknesses are known up front (if not by the development team, then by the security team). What’s more is that these tests lend themselves to a TDD approach in that they can serve as the security specification before building the application and environment.
  Some work has already been done in extracting these types of tests into security test automation frameworks, see: BDD-Security (I’m the author), Mittn by F-Secure and Gauntlt.
  Because these test non-functional aspects of the application, they need access to the HTTP layer which browser automation tools do not provide. So testing these requires a hybrid approach: Browser automation together with a proxy server to inspect and inject requests. My preferred combination here is WebDriver with OWASP ZAP.
3. Security scanning of the application and infrastructure.
  Even manually driven penetration tests usually kick off with an automated scan using vulnerability scanning tools like Nessus, Burp and OWASP ZAP. It’s worthwhile understanding the difference between these tools and how they’re used. Nessus if primarily an infrastructure scanner in that it’ll test an IP address and all exposed ports for known weaknesses. It also includes a “web” scanning component that will test HTTP services for similar known weaknesses, but the scanning at the web tier is extremely superficial. For example, Nessus would not be able to scan any content or functionality behind the login form, nor navigate through a web wizard.
  Burp Intruder (Commercial) and OWASP ZAP (Open Source) are focussed on the web tier and are true application scanners in that they inspect and test at the HTTP layer by injecting attack data into parameters and evaluating the application’s response. They can provide in-depth security scanning if they’re used correctly. But if they’re simply used to spider the application and run an automated test then there’s a good chance that they won’t find or test all the available content.
  To successfully automate application scanning, one should ensure that all of the content to be scanned is navigated and populated in the scanning tool, before starting to spider and scan the application. If you already have acceptance tests that drive a browser, then these can be re-used to populate the Burp or ZAP content before kicking off a scan.
4. Security testing application logic.
  Automated tools can only go so far in detecting security flaws. Toidentify flaws in the logic of the application requires a human brain (at time of writing). From an automated scanner’s point of view an online auction site and an online bank are the same type of application, i.e. a series of HTTP requests. But from a human attacker’s point of view, they are vastly different beasts offering very different functions. A human security tester might try tests such as:
  - Can I manipulate the HTTP Request to bid on an item that has already ended?
  - Can I manipulate the HTTP Request to bid with a high amount, and then modify that amount to a lower amount just before the auction ends?
  - Can I transfer funds to someone else’s account using a negative number as the value?
  These require ingenuity and experience to find, but once the attack is defined they too can be recorded as automated tests and become a part of the security regression tests.
Walk before running

If you’re just embarking on the journey to automate security tests, the above steps may seem daunting. But it’s not necessary to implement all of them to reap the benefits of automated security testing. Points 2 and 3 probably represent the greatest value in terms of time invested vs. security value extracted since they help identify a lot of common security flaws that slip through the cracks in a normal development process.

Any testing framework can be used to orchestrate and run these tests but in the true spirit of SecDevOps, it would be good to choose one that the development, operational and security teams are comfortable using- and that easily integrates with your CI/CD server. I’m partial to the BDD frameworks because their use of a natural language to define the testing steps means that they’re instantly understandable by a wide audience and makes them very attractive for use as security-tests-as-specifications. But some teams that are well versed in programming language X may find this additional, natural language layer, superfluous.

Point 3 above requires an additional step if we want to integrate those tests into a CI/CD environment. The other tests all have clearly defined passing and failing criteria, but running an automated scanning tool typically results in a number of false positive results: security issues reported by the tool which aren’t actually risks. Manual security tests that use automated tools include a process of investigating and removing these false positives. Automated tests would have to do the same thing and also specify a success criteria. This can be done by wrapping the scanning operation in a test and specifying the known false positives given a particular scanning tool and target.

For example, the BDD-Security framework performs an automated scan for SQL injection vulnerabilities using the following test:

and the additional text file: tables/false_positives.table to define the known false positives to ignore:

The final step in the test defines the success criteria and would need to be selected based on the security requirements of the application and the scanning tool used.

When to run the tests

Since they’re automated, the cost of running the tests is very low, so naturally we’d want to fail fast and run them as early as possible. But security issues are typically found at the component level and are difficult to test at the unit/class level. So testing at the application tier should be done on a running application. In other words, at the same time as automated acceptance tests.

Testing the security of the infrastructure should be performed on an as-near-to-live as possible environment. This will typically be a pre-production environment. And of course, since running the tests doesn’t cost anything, there’s a good argument for performing the same tests in production as well- continuously.

Blocking tests or in parallel?

As a security practitioner, I would love to see security tests as part of the CD process and blocking delivery if tests fail. But in reality this may not be practical for all teams; and it’s ultimately a cultural question of how deeply security is integrated into the dev and ops teams.

For those who’ve not achieved SecDevOps Nirvana, the tests can be run in parallel to the build with supervision by the security team. It’s then the security team’s responsibility to manually block delivery if test failures indicate the presence of unacceptable risk.

CI Server Integration

How well the security tests integrate with the CI server depends on the testing framework and CI choice. Java, Python and Ruby testing frameworks are likely to be supported by all the major CI servers. Using Jenkins and JBehave, which produces both JUnit and HTML reports, the tests output would be:
April 6, 2015
Linux Containers & Security Implications

Does the word “container” intimate containment, suggesting that containers are inherently secure? If it does, any such assumption of security may be the broadest Docker vulnerability to date.

“One of the biggest threats I see with Docker is its positioning and the implied security in the language. The reality is that these containers don’t contain anything,” says Aaron Cois, Researcher, CERT Division, Software Engineering Institute, Carnegie Mellon University. Yet, that is the implication.

Just as those who thought Linux or VMs were secure enough on their own were mistaken, so those who believe that containers put a lid on security will be sorely disappointed. Today, Linux environments require network, OS / host security, Internet security, and web application security measures similar to those used with other platforms. Tools like security auditing / PEN testing, firewalls / WAFs, anvi-virus and anti-malware tools, DLP, IDS/IPS, remediation tools, and really the gamut of security measures similar to what Microsoft environments require are increasingly needed to defend data in Linux environments. “Likewise, operations can give developers tools to log into the VSphere console to create and change VMs while limiting their privileges,” says Cois.

And so, containers also require appropriate security measures. “Developers and non-admin operations staff don’t need to log into the host command line to work, and no one in security wants them to,” says Cois. But today’s Docker workflow not only permits but requires it.

The Root of the Problem…

–THIS STORY HAS BEEN MOVED TO CONTAINER JOURNAL–

March 16, 2015
Dev and Ops Coming Together To Combat the Weakest Security Link – BYOD
Traditionally, security threats have taken the form of intentional acts by remote attackers: somebody on the outside working covertly to get to the inside. This is the classic scenario that most people associate with IT security, and it’s what most network operators are best prepared for. But these classic threats are eroding rapidly in the era of ubiquitous mobile devices and users who’ve become accustomed to always-on network access. BYOD is the weakest security link today.

The surge in mobile wireless devices has blurred the line between what is inside and outside the network. Mobile devices such as smartphones and tablets are legitimate, and increasingly indispensable, business tools. Immersed in social media and digital technology, many Millennials treat their mobile devices as extensions of themselves, making it very difficult to separate one from the other. The obvious cost of a policy that prevents users from bringing personal devices to work is impacting the recruitment of new staff, and sometimes depriving existing staff of the tools they need to stay competitive, but the risks are also substantial.

The Technical User

While many fear the untrained user, the worst threats may come from the technically literate user, such as a developer or engineer, who feels he or she simply cannot work without their mobile device and unfettered access to the network. Such a user may not take no for an answer when it comes to bringing in their mobile device, and may even go so far as to employ their own personal hotspot hardware or software to bridge the gap between the protected work network and their unauthorized devices.

No ill will is intended by this act; the user simply thinks s/he knows better. S/he wants to be able to use the devices that make work life easier and knows how to set up an access point to do just that. They don’t realize or just ignore the fact that an access point outside the purview of IT security or ops poses a significant risk to the network as a whole. Without being able to verify the integrity of the hotspot or its configuration, ops can’t be sure if it’s being held to the same security standards as the rest of the network.

While these technical users know how to bypass the system, they may not know how they are leaving their network open and vulnerable. A developer with access to sensitive information, perhaps even branches of source code, may be restricted by the security team from accessing certain portions of the Internet while on the developer network. A technically adept but perhaps not security-conscious developer could attempt to bypass these restrictions by setting up an access point of his or her own – though this may give him or her access, it also gives attackers access to his or her machine. Developers have sensitive information on their laptops that needs to be protected, and connecting to unsecure networks can put this IP at risk. A developer bridging the network using a 4G adapter or access point not only exposes the information on his or her laptop; it also creates a hole that could expose the entire network to infection. Being alerted to these access points is an important step in validating your security controls.

Best Practices: Finding a Balance

The most important steps for creating and implementing a security policy that works both from a security and an efficiency perspective are elaborated below: assess your developers’ needs, set reasonable controls, and validate those controls. Together, they represent a balanced approach to addressing the often conflicting needs of an organization.
1. Assess Your Developers’ Needs
Preventing developers and technical users from connecting devices to the network, or placing overly restrictive limits on their devices, can inadvertently lead to more security issues than otherwise. With overly restrictive policies, users are more likely to take matters into their own hands and bypass security controls. The best course of action is to engage these users to determine what their work motivations are, and meet them as closely as the overall security and operation of the network will allow. Ideally make the users allies to ops, not adversaries. These developers are knowledge workers, often well compensated, with some degree of entitlement, and cultivating an environment of trust and cooperation is in the best interests of all involved.
1. Set Robust – But Reasonable – Security Controls
This may be stating the obvious, but the most important part of empowering your developers is to mutually set expectations. Properly established security controls are really just agreed-to expectations, laid out in a manner that allows developers to understand what is expected of them and how to appropriately bring up concerns or exceptions. These expectations should be both reasonable and attainable. The most important part of adopting a “bring your own device” (BYOD) policy is to adopt one that meets the needs of the developers while maintaining security and validation. An inappropriately onerous process will encourage users to bypass the process, leading back to an insecure environment with gaping holes in network security. There is a range of tools to consider that can support controls. For example deciding if managed device management (MDM) tools are to be used or not is a major consideration that will drive controls and network access.
1. Validate Controls with Visibility
Security controls are frequently talked about, but less often mentioned is the validation side of the process. You can establish as many controls as you feel necessary, but without visibility into the network, controls are more words than reality. While seeing access points is important to evaluating the risk at your offices, it is only half the battle. The most important thing is finding devices operating on the access point and understanding what access they have to the internal network. With a list of which devices have been attached to the access point in question, it’s a simple process to identify where an offending device is located, and who is responsible for its existence.

Once you’ve found the rogue access point and its operator, it’s time to perform triage. Was the access point connected directly to the business network, or did it get Internet connectivity over the cellular network? If it was on the business network, what kind of access did it have? Was it behind a firewall, or did it expose critical network components such as servers to the outside?

These types of questions will help steer the subsequent investigation and save valuable time. It may end up that the access point posed no direct threat to the business network itself; such as the case of a personal hotspot tied to a cellular modem. In that sort of best-case scenario, the network operations team may simply need to reinforce the rules and regulations of the network, and explain the importance of keeping the network isolated from the outside world.

What Does a Rogue Access Point Make Vulnerable?

While these rising risks have grown with the erosion of classic IT boundaries, your information is still both valuable and vulnerable. Data and Intellectual Property are two of an organization’s most valuable assets; without good security processes, quick development cycles are futile.

About the Author/Paul Paget

Paul Paget is the Chief Executive Officer of Pwnie Express, provider of end-to-end security assessment solutions. He brings more than 30 years of of leadership experience in technology companies and information security to the company. Follow Paul on Twitter: @pgp2
March 16, 2015
To Be or Not to Be – Shadow IT

Is it being an innovator, or demonizing business decisions to use other vehicles, and cry foul?

Sun Tzu, the famous Chinese strategist and philosopher, once said, “If ignorant both of your enemy and yourself, you are certain to be in peril.” These words ring true to the quandary that traditional IT organizations find themselves in today: on one side, hordes of tech-savvy business users are deploying and engaging technology services at an alarming rate, often without any input or validation by the IT team. On the other side, there’s an aging on-premise infrastructure that requires frequent care and stresses the limited resources and budgets of IT staff. In between, sits a group of technology professionals that want to support their users while maintaining the appropriate level of compliance, risk management and security — fondly known as “Traditional IT”.

Security teams, a part of traditional IT organizations, have begun demonizing any non-sanctioned technology use – dubbing it “Shadow IT – taking a somewhat close-minded view as to how software and services are being procured and utilized in today’s organizations. In the legacy world, IT Security could block or veto projects based on its merit and risk. Business teams had no choice but to work within their constraints, as the security teams controlled the firewalls — the proverbial gates to the kingdom. Nothing entered or left the organization without being blessed through the firewall, which left IT Security in a very advantageous position. Fast-forward to today and we see a drastically different dynamic taking place in organizations: DevOps and business teams are driving buying decisions, or making them without IT approval.

Why is this happening?

If you look at how various teams are structured in most organizations it becomes obvious. IT departments, a legacy construct best suited for organizations with few technology-savvy users, are best suited with a role as a service provider. Meaning, they build infrastructure, deploy software and services, and operate utilities as a service to their user base. This could be users in the form of bankers, call center employees, or even software engineers. There is no minimum or maximum level of technology expertise required on behalf of the user, because the IT department is there to offer support and guidance as necessary. This is very much a “thou shall not use technology not provided by IT” point-of-view, because IT is ultimately responsible for the support and user experience of said technology.

However, IT departments are fundamentally based around annual budget cycles and 3 to 5 year amortizations of capital expenditures (servers, network equipment, etc.). As the quality and variety of software, hardware and SaaS solutions has increased ten-fold over previous decades, we have quickly entered a buyer’s world where multiple satisfactory solutions can be obtained quickly. This is counter to the traditional IT pattern of planning purchases in advance, leaving ample time for procurement haggling. In as little as a year, entire service providers can spring up with scalable, resilient, superior technology solutions — often affectionately referred to as disruptors. These disruptive technology companies move fast, gather feedback from their customers, improve their product/service and deliver new products. If you just spent a million dollars on servers that you plan on keeping for the next three years, it is nearly impossible to justify leveraging a fleet of cloud servers as an alternative just a few months later. The cloud servers could be the right solution for your business — but the pain of wasted capital is too great for most organizations to shake, much less the implied defeat or mistake in judgment by IT management.

DevOps teams, on the other hand – and much to the chagrin of IT and InfoSec teams, thrive in the chaos of moving quickly and breaking from tradition. This is not done maliciously, but rather out of necessity to reach a peculiar and demanding audience. Years of “buy it now” instant gratification have conditioned the end-user to expect fast, high-quality and competitively priced products. This holds true for the Internet generation now responsible for the buying decisions of everything from inexpensive productivity tools to enterprise-grade communications solutions. Decisions are not made solely on who can deliver the highest SLA or who had the best benchmark score. Agile teams now look for the best product fit, defined by a set of conditions ranging from automation integrations to direction and vision of the vendor. This wide range of criteria falls well outside the traditional IT buying spectrum, and thumbs its nose at the legacy buying practices. DevOps teams buy subscriptions to services that they can change or cancel at any time. They procure products that don’t even have user interfaces beyond an API and JSON output. They buy based on “what can we do with this” rather than “what can this do for me”, which is reminiscent of maker culture.

A new breed of tools that enable the DevOps teams to do great things while catering to the IT Security team has emerged. DevOps teams tend not to budget for security, and are often too fast moving to build all the requisite capabilities themselves. IT Security is desperate for a place at the table to ensure the safety and security of organizations and its users. This sets the stage for new, emerging technology companies to capitalize on the widening gap that has occurred as the industry shifts from the traditional datacenter model to one of private, hybrid and public clouds. This means no more 3-5 year investments in a security technology and no 3-5 year guaranteed relationship for security vendors. Emerging companies also have to raise their game to meet the needs of these organizations and prove to be the partner of choice. The uptake to date has been slower as the industry has been slow to detect and understand this shift. Many organizations have legacy investments and don’t want to bring additional complexity to their lives by adding new panes of glass. DevOps teams may directly integrate raw data feeds from new products into their toolkit, but IT teams need solid integrations to existing infrastructure to make the best use of these new products. Without this, they can’t keep pace with the rapid deployments and changes made by DevOps teams, and are left nearly blind to the dynamism of their infrastructure risk and security posture.

So what is the solution?

It’s simple. By integrating security more deeply into the DevOps toolchain, and operationalizing security practices the same way we operationalize infrastructure and code issues. This means there is a space to not only bring cloud-centric data down to the legacy investments through connectors and integrations, but also an opportunity for IT Security to enable DevOps by automating common security practices. If the practices and behaviors of Security teams were operating at or beyond the pace at which DevOps teams deploy, then a collaborative environment can be built with security detection, notifications, and even mitigations act as a “safety net” in agile environments. This makes a lot of sense when you realize that the biggest threat to these agile organizations is not malicious hackers or state-sponsored attacks, but rather human error, policy failure, lack of transparency into security practices, and lack of consistency over time.

About the Author/Tim Prendergast

With well over two decades of experience pushing the limits of technology, Tim set out to create the first “next-generation” security company, Evident.io, focused solely on programmatic infrastructures (cloud). Tim co-founded Evident.io to help others avoid the pain he endured when helping Adobe adopt the cloud at a massive level.

Tim’s prior experience includes leading technology teams at Adobe, Ingenuity, Ticketmaster, and McAfee. He holds over 15 years of security experience; 8 years of AWS security experience, with 3 of them defending the Adobe AWS infrastructure from inception to production as an AWS Certified Solutions Architect.

Connect with Tim: LinkedIN | Twitter | Evident.io

February 25, 2015
Security Should Be the Top Driver for DevOps

I’ve often said that the driving factor for many companies in adopting a comprehensive information security program are the dreaded “F” and “A” words – FUD and Audit. Technically FUD is an acronym for fear, uncertainty and doubt. And it might be better said that audit is the action used to hopefully demonstrate compliance and trust.

Just a few years ago, the predominant drivers for security spending were regulatory and compliance requirements. While compliance remains a driver today, the primary moving force for many is the concern of cybercrime. Fear of being the next Sony, Target, Chase or countless other victims is driving information security budgets to be readdressed.

In a recent CA survey the top obstacle (28%) to DevOps in their organization were security or compliance concerns. Yet, in the same study, a huge percentage (88%) already have or plan to adopt DevOps in the next 5 years. The dichotomy of the situation has not escaped me. Organizations are in a situation where they are actively spending money on DevOps and information security, but at the same time view these two initiatives as counter.

The answer is simple, information security teams need to adopt DevOps principles.

While a widely agreed upon definition of DevOps is still up for grabs, its safe to say that DevOps is generally inclusive of a few core tools and principles. First, DevOps promotes a culture of cooperation and sharing among different groups in an organization. Second, DevOps promotes the use of heavy automation, decreasing time to market and agile development.

Information security’s goals are the CIA triad – confidentiality, integrity and availability. Security teams argue that DevOps is the antithesis of good security. Constant change, open culture and automation smack directly in the face of security’s tactics of compartmentalization and tight process control.

Here is a little secret – DevOps is winning, information security is losing.

DevOps teams are deploying code faster and faster. They are reducing time to market and increasing revenue. Information security teams, well, lets just say that they continue to be in the news for the wrong reasons.

The second little secret – the companies which are really winning are using DevOps tools and principles everywhere in their organization. Even in information security. Imagine overseeing infrastructure configurations with code that ensures compliance 24×7 across an entire organization. Or picture being able to instrument thousands of data points to benchmark security performance over time. Conceptualize being in charge of an automatic closed-loop security system which automatically takes action to mitigate attacks based on shared threat intelligence. These are possible with DevOps.

For all that DevOps provides, security should not be a hinderance to DevOps adoption. Instead, security should be a top driver for adopting DevOps. Using DevOps to create the next generation information security program might just be your only hope in combating the next cyber threat.

January 22, 2015
Gartner gives Docker security an ambivalent thumbs up

As organizations continue to evaluate wider spread use of containerization to enable continuous deployment, security concerns around the wildly popular Docker keep popping up. Last week, an analyst with Gartner published a report that gave Docker security positive marks with some big caveats.

Written by Joerg Fritsch, the report examined the security properties of Docker. According to Fritsch, Docker is effective at resource isolation and has already just about attained parity in secure operations management and configuration governance with Linux OS and hypervisors . But where Docker containers fall short is on the management end.

“They disappoint when it comes to secure administration and management, and in support for common controls for confidentiality, integrity and availability,” Fritsch wrote, explaining that this could improve as Docker refines its libswarm and nsenter APIs.

As things stand, Fritsch recommends that organizations that don’t need to emulate a virtual private system should standardize on nsenter for interacting with running containers, and protect nsenter by limiting the input set. He also recommends that when working at scale, organizations should select a framework for managing resources and deploying containers, and consider using SSL/TLS wrappers for the Docker/Swarm API for the sake of integrity and confidentiality.

Meanwhile, Fritsch particularly calls out the lack of endpoint protection platform and encryption tools for Docker containers, explaining that the outlook is “grim” on this front.

“Traditional EPP and encryption vendors have not yet recognized containers as an area that they need to pursue and secure in the future,” he says, explaining that organizations have to mitigate risks through application whitelisting, SELinux or by using a strategic DevOps tool chain to automate and secure their containers, essentially making “containers self-assessing entities.”

Third party vendors may take more note of Docker as 2015 progresses, particularly if Docker’s growth follows the same trajectory in 2014. From June to October alone, Docker’s downloads grew from 3 million to 21 million. And last fall Docker received venture support for future growth by way of $40 million in additional funding—following up a previous round of $15 million in funding earlier in the year.

However, security concerns around Docker have started gather like storm clouds. In fact, security objections over Docker were a big reason for the introduction of the Rocket containerization project by CoreOS in early December. That announcement came swift on the heels of the release of the 1.3.2 version of Docker Engine, which took care of a number of vulnerabilities that could be exploited through a malicious Dockerfile, image or registry. It also added added a security feature for validation of images in containers. However, by late-December, security pros were knocking that verification function.

“Docker’s report that a downloaded image is “verified” is based solely on the presence of a signed manifest, and Docker never verifies the image checksum from the manifest,” wrote Jonathan Rudenberg, co-founder of Flynn, in a long explanation of the insecurities in Docker’s image downloading process. “An attacker could provide any image alongside a signed manifest. This opens the door to a number of serious vulnerabilities.”

January 20, 2015
Webinar: Security & DevOps in 2015
The intersection of Security and DevOps. What does 2015 hold in store? Organizations are under increasing pressure to do more, faster. But cybersecurity breaches by criminals, hacktivists and state sponsored actors have cast a shadow over large portions of our IT infrastructure. How can security and DevOps in tandem make us safer while allowing us to increase speed and quality? This webinar features a panel of experts in security, development and operations. We will explore what this year and beyond holds in terms of help as well as pitfalls. What can you do to build more security into your processes? How can you be compliant, secure and efficient? This year promises to be a watershed in security and DevOps. Join us in this webinar to hear an expert panels views on what it means to you.

YouTube playback of the webinar:
Slides

[seoslides embed_id=”81ba77e9dda4″ script_src=”https://devopsy.kinsta.cloud/embed-script/security-devops-2015/4126/” overview_src=”https://devopsy.kinsta.cloud/slides/security-devops-2015/4126/” site_src=”https://devopsy.kinsta.cloud” site_title=”devopsy.kinsta.cloud” title=”security-devops-2015-webinar” /]

Date: Thursday, January 29th, 2015

Time: 1pm eastern standard time
```
REGISTRATION LINK:(CLOSED) 
```
About Speakers:

Moderated by devopsy.kinsta.cloud co-founder and editor-in-chief Alan Shimel, the experts on our panel are:

James Brown is Chief Experience Officer at JumpCloud. He works with the JumpCloud team to define product strategy, and set the overall usage and support experience. James’ background is in system administration, software development, security, and product management.

Tim Matthews is VP at Incapsula. Tim brings over 20 years of software sales and marketing experience at security and technology companies to Incapsula. Prior to joining Incapsula, Tim was CMO of CrowdFlower, the leading SaaS crowdsourcing platform. Tim holds a B.S. in Computer Science from Union College in Schenectady, NY.

Stephen Coty is Director of Threat Research at Alert Logic and also the author of the Cloud Security Report. In his role at Alert Logic, With his wealth of experience in the security space, Stephen is currently in the process of building a premier threat research team that is innovating the industry. He is also a member of ISSA, Infragard and the HTCIA.
January 19, 2015
Automating Away the Regulatory Compliance Myth

At the recent DevOps Enterprise Summit, we had a chance to sit down with Justin Arbuckle and discuss his concept of “compliance as code” and why it’s so important that security and compliance tests be built into DevOps practices at large enterprises. Recently, Arbuckle was chief architect at GE Capital where he introduced and sponsored DevOps at that organization – so he certainly knows about what it takes to “do DevOps” in large, highly regulated environments.

Currently, Arbuckle is the vice president of EMEA at CHEF and also chief enterprise architect there. If you watch his talk from the DevOps Enterprise Summit, Hunting the DevOps Whale, you’ll see that he is passionate about the transformative potential of DevOps in large enterprises.

At CHEF, Arbuckle is in helping large enterprises understand how to “de-risk” their migration to cloud with automation. We caught up with him at the DevOps Enterprise Summit to ask why that is so important. Here’s what he had to say.

devopsy.kinsta.cloud: When it comes to DevOps and regulatory and security concerns, many people say, “Well, just automate those tests.” What does that mean, to you? How do you “automate in” security and compliance?

Arbuckle: I think, in terms of the specific issue of regulatory compliance, a lot of what we think of as the being compliant process today is a complete myth. There is just so much detail that needs to be checked that the organization is always in a position where they have to trade off against, “It’s good enough, we’re ready to go” versus, “We’re not going to go anywhere until we’ve literally crossed every T and dotted every I.”

The reality is that a lot of the regulations, Dodd-Frank is a good example, are getting to a level of detail where they’re beginning to talk about process. They’re beginning to talk about how you design product. They’re getting very deep indeed.

So the organization that has to govern that, can’t do it based on just this idea of oversight at particular points in the life cycle. Because if you’re going to do it properly you literally slow your velocity to zero, and so you’re making a trade-off between compliance and competitiveness.

The way to break that cycle is to, and this is a big paradigm shift for regulators, a big paradigm shift for compliance people inside organizations, you have to start being able to express those compliance requirements in a form that’s codable. Using something like Chef for instance what we’re able to do is we’re able to specify a particular policy in a way that is automatable. In a way that we know is always going to be implemented every single time.

devopsy.kinsta.cloud: Would that include input from security people, compliance teams, design teams, system architects?

Arbuckle: Absolutely. Honestly, in my experience I think the number of organizations that can count fully detailed, fully implementable — and that’s the key word — security policy by their infrastructure people is countable on one hand.

Generally speaking, there are many obvious guidelines that are standards-based. But as the security organization tries to keep up with security threats, they’re obviously learning as they go. In this way policy always lags. And the only way for the organization to catch it is through this process of documentation, policy, and checks. And through it all they know that the standard is nonsense because it’s out of date by definition. So they have to create a point-in-time review. And these point in time reviews bring velocity to a halt.

devopsy.kinsta.cloud: Yes. Especially when something is wrong. They hit a red button and everything stops coming off the assembly line.

Arbuckle: That’s right. The approach that we have to get to is the idea of policy as code. But you are not going to be able to, on the first go, be able to codify everything. Very often with automation, based on my experience, is that the difficulty at large enterprises has actually less to do with the tools and more to do with knowing what you want to automate. Knowing what you actually want to put in infrastructure as code.

It’s the same thing with security teams. Ask them to go through the most important things that need to be tested in automation, and getting them to go through that process. It’s often difficult because they are not development people typically. They’re not infrastructure people, And they’re not operations people.

They’ve kind of created their own “securocracy” if you like.

What security teams have to do is understand their work is subject to source control as well. Their work is subject to variation and evolution over time and we should write tests to ensure that the following policies are being applied consistently.

DevOps: And I assume these tests are designed over time, as one goes along? For example, if there’s a new malware or regulatory beast that you haven’t seen before, you can design a test and then implement that as part of the life cycle?

Arbuckle: That’s exactly right. And the great thing about tests is they are additive. You’ve got a test that tests for the range of ports that are open on the operating system and then you add another test, maybe testing for the types of applications that are installed on the box. They are two separate tests and they are additive. So as you continue, you build up your library of tests.

And for most organizations going through the adoption of test driven development, as an example, they have to do it that way. A large application that is beginning to develop in an agile way is going to have a lot of tests. If you take a typical large core banking application, for instance, it will probably have something in the region of about 5,000 use cases. That’s thousands and thousands of tests. Let’s just agree that in no short period of time are you going to write those tests.

devopsy.kinsta.cloud: That’s an enormous catalog of tests. How do you keep them up to date and fresh? I imagine as security changes, regulatory compliance changes, you may have to tweak these tests as you go along. How do enterprises keep up?

Arbuckle: Like any requirement you have stakeholders that are responsible for those requirements. In just the same way, if you had for instance a mobile application and you have a product owner for that mobile application and that product owner is prioritizing feature sets you should also have a product owner for compliance.

And the product owner should be detailing what the set of compliance requirements are for the product.

Essentially compliance is embodied in the tests that are run against the appropriate applications. And so to manage automation and compliance as code, you need to have a product owner for compliance. And compliance as code, or automation, is the way it has to be in order for compliance to actually be true and consistent, as opposed to a myth.

November 4, 2014
Webinar: What DevOps Need To Know About Web App Security
You’ve seen the headlines— With Global Presence Falls Victim to Hackers. These data breaches result in the theft of millions of names, passwords, credit card numbers, and other personal data. Imagine the consequences of a breach leading to the theft of your confidential data. . .

If multi-national companies with dedicated security teams and expansive budgets aren’t immune to the impact of hackers, how can you adequately prepare yourself to defeat this threat?

What can be done to make apps more secure? From both development and operations, how can web app security and DevOps work together to make it better?

This webinar will explore the web application threat landscape. It will zero in on some of the most common attacks wreaking havoc on the internet, teaching you how to defend your online assets from them by leveraging development and operations teams to be more security aware.

Date: Tuesday, November 11th, 2014

Time: 2pm eastern standard time
```
REGISTRATION LINK: (Limited registration, so don't wait!) 
```
About Speaker:

As Product Marketing Manager for Incapsula, Orion Cassetto is experienced in web application security and SaaS security solutions. Orion previously held product marketing positions at Imperva and Amorize Technologies as well as having earned degrees in Asian Studies and Chinese Language from Washington State University.
October 22, 2014
Moving Security To the Left In a DevOps World

Moving security to the left has become a coined phrase meant to describe the process of getting the security team involved earlier in a process. Most typically, the phrase is used in conjunction with IT or software development projects. One of the top suggestions for ensuring security in a DevOps world is to move security to the left in the process tool chain. But what exactly or how exactly can you move security to the left?

Grab that Open Seat

The new DevOps process pipeline created an opening for a seat at the table for security. Prior to DevOps, the development team owned the entire pipeline from plan to release. The Ops team would historically receive the release from over the wall and then be responsible for the deployment and operating the software inside the production environment. With the Ops team joining forces with Development in the process pipeline, that has opened a proverbial seat at the table. What I’ve started to witness are security teams taking advantage of the musical chairs to quickly grab the open spot.

Taking a seat at the end of the development pipeline is not enough. Too many security teams are still being relegated to positions too late in the process. While running pen tests and security code reviews after a release is better then nothing, its still not ideal. Security needs to find ways to add value to the process so they can act as a force for positive change instead of the after thought.

Threat Vector Analysis

Threat vector analysis is part science and part art and part trying to guess uncertainty. What is certain, however, is that most developers would rather be spending their time writing new functionality instead of trying to understand how an attacker could be break their code. The security team could offer a tremendous service to an organization by offering their expertise in this area.

Continuous Integration Security Testing

Continuous integration is a key component of DevOps. The security team can leverage the development chain to insert early yet important risk control tests. Those tests could be for example static or dynamic code analysis. Other tests could be simple yet known vulnerability checks in included libraries. The OWASP introduction to testing guide lists a plethora of application security tests that should be checked often and early.

Author Micro Security Services

Think about how great it would be if there was a group who specialized in authoring and delivering security related services into your application? Proponents of services models generally promote splitting the development team up into groups that are organized around business capabilities. For example, there are separate development groups for UI, middleware and DB. What’s missing in most of those models is who is responsible for security services such as authentication, authorization and audit. Security has an opportunity just waiting for them to add incredible value while also ensuring the security services used pass muster.

Summary

Where we once had Ops fighting their way to be part of the entire development process, we now have security trying to do the same. Ops managed to garner their way into the club by coming to the table with invaluable skills and resources. Now its up to security to present their creative sweet spot in order to secure their own seat at the table.

Further Reading

Andi Mann on Ensuring security and managing risk in enterprise DevOps

October 1, 2014