devopsy.kinsta.cloud

Category: DevSecOps

Minimum Viable App Doesn’t Mean Minimum Security

It’s estimated that the total market for mobile apps will hit $143 billion this year. A big portion of that budget will be enterprise mobile app development. By next year 25 percent of enterprise IT budgets will be aimed at their mobile app efforts. Yet, despite these efforts, most enterprises are still falling behind in their mobile app development pipelines by 12, 15 and even 20 weeks.

To help clear that backlog and meet their internal mobile app demand, more enterprises are focusing on delivering the mobile apps with the features that hold promise to produce the most return on their efforts; that is, the apps that people likely will use and will do the most, for the least investment, to help to improve their daily work lives and productivity. Or, this minimum viable product (MVP) is the minimum required in an app to prove out its app concept.

But when moving apps out quickly, enterprises risk skimping in areas of quality and especially security, which can pose a risk to data that should be handled with care, notes Isaac Potoczny-Jones, research lead, Computer Security with security research and development firm Galois.

“There’s definitely a lot more development in mobile happening,” says Potoczny-Jones. “I think the [security] best practices in mobile aren’t as well-developed as best practices for the web. I think that’s getting a little bit better, and there’s a very fascinating challenge with security [with MVP] because security is a non-functional requirement.”

Of course, apps must be developed with good mobile security—including app password management, server side controls, cryptography and other best practices—in mind. The OWASP Top 10 Mobile Security Risks provides an excellent overview of common mobile risks and associated mitigations.

One of the challenges with mobile security testing is that the best practices and associated processes are not well understood by most, at least not yet, and quality mobile security testing tools are not deployed in many organizations. Plus, those organizations using some of the common mobile security testing tools find that they don’t always suffice and they often have to build their own automated toolsets.

The risk with fast-tracked MVP apps is that they never get anywhere near a security test before being shipped to production. But these apps—just like any other apps that get near enterprise data and networks or may access sensitive, confidential or regulated data—must be vetted, threat modeled and tested (static and dynamic app testing), along with the usual quality tests. And with MVPs, it’s just as important that this testing be an integrated part of the process from the beginning.

The best way to achieve this, of course, is through awareness and secure code training with developers.

Companies may want to consider creating an MVP development guide that could detail security considerations for the MVP. Such a guide could help developers determine what security best practices to follow, as well as what apps need to be sent to the security team for reviews—and when.

Potoczny-Jones says there’s no reason, except for maybe carelessness, why MVP apps are being built with minimum security considerations, as most lean development methodologies have security testing built into their processes. “Once you get these teams to include security testing being a part of [what they consider] ‘being done,’ which I don’t think a lot of people have, then they’re going to do the right things. You’re either going to start to build security either into the user stories or the acceptance testing,” he says.

That’s for sure, and it shouldn’t be left to the end of the development process. “You can’t leave it to just be at the end of the process. If you leave security testing toward the end, naturally your schedule is going to slip. You’ll find that there’s a lot more work to do. Then you’ll be in this unfortunate position of having to decide whether to fix things and let the schedule slip, or choose to let something go out the door that’s not secure,” Potoczny-Jones says.

February 10, 2016
Cloud Security: Software Defined. Event Driven. Awesome.

I get it. Cloud and DevOps are disruptive and create new risks. I’m a security pro; one with decades of hard-earned experience telling me that with great chaos comes great opportunity… for the bad as much as the good. And once again it’s time to circle the wagons, make sure policies are enforced, and our organization’s are protected. Or maybe that’s just all the subliminal vendor FUD leaking past my mental firewalls.

But maybe it’s time to tell that part of my brain to shut the blank up and start looking for all the ways cloud and DevOps make things better for security. Because they do. And not merely on the surface, but in deeply fundamental changes that upend a lot of our previous conceptions. The best part is that, for once, all of this is real, practical, and achievable today.

Major cloud providers provide solid security foundations (otherwise no one can use them), typically better than most self-managed data centers. Great baseline security is all well and good, but I’m far more interesting in ways cloud enables us to do security better. Not a little better, but fundamentally improve our existing practices, processes, and capabilities. This isn’t a theoretical concept, but a practical one that some of us are using today in the real world, and I’m going to show you a concrete example.

These capabilities are thanks to Software Defined Security and Event Driven Security.

Software Defined Security is the ability to programmatically manage our security technologies, including the security capabilities of non-security technologies. For the most part it’s been an abysmal failure since security companies don’t exactly have the best track record when it comes to APIs and automation (well, outside of marketing materials). Even today the burgeoning on-premise automation tools often find themselves having to remotely log into consoles and issue command lines to manage activity. Security automation has usually been a good way to automate your rapid departure from your current employer.

Cloud computing changes that in two ways. First, the broad accessibility of robust REST-based APIs to manage security features of cloud services and, on occasion, security tools or services themselves. SOAP APIs are usually too difficult to work with for anyone short of dedicated developers, while REST is often consumable for strong scripters and admins. Second, the non-security APIs allow security professionals to integrate with the infrastructure and platforms directly. We now use the same interfaces as operations and development, except we can use them to achieve security objectives.

For example, at various conferences I demonstrate an automated incident response workflow that quarantines and instance, locks down the AWS management, images the storage, launches a forensics analysis server and connects the images, and performs a deep analysis of it’s state, connected resources, and potential exposure. An old version is up on GitHub and I have a vastly updated version I’ll be releasing soon. All of this happens in a few seconds.

Another example, in that same project, nearly instantly identifies any instance in your account not managed by Chef. Identifying unmanaged servers in a traditional network is a common audit function that takes weeks or months. In cloud computing it’s two API calls and a three line comparison function. Last year at the RSA Conference I demonstrated automatically inserting a cloud WAF in front of detected web servers in less than a minute.

The second piece of the puzzle is newer. With Event Driven Security we leverage the core instrumentation of infrastructure and platforms to detect events and initiate security automation. Until now nearly all security tools relied on polling/scanning or custom agents that have a pesky tendency to kill performance or otherwise break things. For example, instead of scanning the network to detect a change, the network tells us when it changes, and that event triggers actions. It’s a subset of Software Defined Security, yet still distinct.

In this example I posted earlier this week I leverage Amazon’s new CloudWatch events and Lambda to automatically revert any security group changes, or only changes that fail to meet certain criteria, within 10 seconds. You could use the some template to reverse nearly any change in your environment, or kick off more complex workflows like the automated incident response.

Software Defined Security allows us to build security operations that are as elastic and agile as the cloud itself. Event Driven Security further reduces the changes of manual error, bringing even greater automation and speed, especially when paired with frameworks and concepts like DevOps and immutable infrastructure. These aren’t new concepts, but unlike in the past they are viable and actively used by real organizations in real production environments.

The combination fundamentally changes how we can build our security programs. Yes, we can still do all the old things we’ve always done, but with a little creative thinking we gain entirely new, and practical, capabilities. It’s a ridiculously exciting time for our community and profession.

February 5, 2016
DevOps Connect: Rugged DevOps @ RSA Conference
Once again this year devopsy.kinsta.cloud along with Sonatype, The Nexus Community, Gene Kim, Josh Corman and Mark Miller are producing DevOps Connect: Rugged DevOps @ RSA Conference.

The full day event takes place at the Moscone Center on the Monday of RSA Week, February 29 (it only comes once every 4 years), 2016. After the day packed full of sessions there will be a cocktail reception* as well. *Cocktail reception requires separate registration.

Last years event had over 700 people in attendance and featured a great lineup of speakers. This year’s lineup is even better we think. It features leaders from both the DevOps and security communities with some great practitioner accounts of how DevOps helps security and how security helps DevOps.

Thanks to the generosity of our friends at RSA Conference, we have a larger room this year to accommodate more people. Anyone with any type of RSA pass is welcome.

What’s that, you don’t have an RSA pass? No problem. Use code 1U6DEVXPO when you register and save $100 off of an RSA full Expo pass. This should make your pass free if you register right away or only $25 if you register later.

With your RSA Expo pass not only do you have a ticket to to DevOps Connect: Rugged DevOps event, but you have a ticket to a full week of attending the RSA Expo floors. Sounds good to me. You can head over to REGISTER here. But don’t wait, there are less than 30 days to RSA!

Also you can get a lot more info about the speakers, abstracts, backgrounds etc. on the DevOps Connect: Rugged DevOps website.

So don’t wait. Register today as seating is limited and on a first come, first serve basis. Looking forward to seeing you at DevOps Connect: Rugged DevOps!

Here is a quick look at the full agenda:
- 8:30 AM – 8:50 AM |Doors Open
- 8:50 AM – 9:00 AM |Welcome & Overview | Alan Shimel, Mark Miller
- 9:00 AM – 9:20 AM |Chocolate and Peanut Butter (or some such) | Josh Corman, John Willis
- 9:20 AM – 9:40 AM |What’s Hiding Under Your DevOps Rocks? | Jez Humble
- 9:40 AM – 10:00 AM |The State of DevOps Data Science | Nicole Forsgren
- 10:00 AM – 10:40 AM |The Darker Side of DevOps and Security | Bruce Potter
- 10:20 AM – 10:40 AM |Break
- 10:40 AM – 11:00 AM |2016 in Review: Failures in Public Safety and Privacy | Kim Zetter
- 11:00 AM – 11:20 AM |Seven Habits of Rugged DevOps | Amy DeMartine
- 11:20 AM – 11:40 AM |Applying DevOps principles to address dynamic changes in Cybersecurity | Aaron Volkman, Hasan Yasar
- 11:40 AM – 12:10 PM |Panel: “DevOps Engagement: Politics, People and Process” | Goerlich/Thrasher/Corrierre/Wang
- 12:10 PM – 1:20 PM |Lunch Break
- 1:20 PM – 1:40 PM |The Journey to DevSecOps | Shannon Lietz
- 1:40 PM – 2:00 PM |Rugged DevOps: Compliance at Velocity | Justin Arbuckle
- 2:00 PM – 2:20 PM |Building Security Controls Around Attack Models, Not Gut Feel | Stephan Chenette
- 2:20 PM – 2:40 PM |Release Engineering’s Role in Rugged DevOps | J. Paul Reed
- 2:40 PM – 3:00 PM |Silver Linings for Miles: DevOps for Building Secure Solutions | Andrew Becherer, Zane Lackey
- 3:00 PM – 3:20 PM |Break
- 3:20 PM – 3:40 PM |Security Wargames | Sam Guckenhiemer
- 3:40 PM – 4:00 PM |Bridging Security and DevOps using an Attack Driven Approach | Earnest Mueller, James Wickett
- 4:00 PM – 4:20 PM |Architectures, Design Patterns, and Coding for Rugged DevOps at Scale | Rich Mogull
- 4:20 PM – 4:50 PM |The R.O.A.D. to Rugged DevOps for a Major Airline | Dan Glass
- 4:50 PM – 5:00 PM |Final Thoughts | Alan Shimel, Mark Miller
Also a special thank you to our sponsors:

HPE, Illumio, Cloud Passage, Evident.io, CA Technologies, TwistLock and RSA Conference!
February 2, 2016
Continuous Security Key to Defending Your Data Well
Defending data isn’t easy. If it were, we wouldn’t see new data breach headlines on a weekly—or sometimes even daily—basis. That said, defending data also isn’t rocket science. A new report from Nuix highlights some of the major concerns with protecting data, and also illustrates some of the ways in which consistent vigilance is half the battle.

The Nuix report, compiled by principal researcher Ari Kaplan, covers a broad spectrum of concerns related to data security. Some of the key findings from the report include:
- Increased granularity of security budgets: Respondents report there is a growing trend to specify how the security budget should be broken down and allocated.
- Regulatory impact on spending has doubled: Government and industry compliance mandates continue to take a sizable bite out of security budgets.
- Greater focus on insider threats: More than 70 percent of respondents have some sort of insider threat policy or program.
- BYOD continues to play a role in security: 82 percent of respondents have some sort of BYOD (bring your own device) policy in place. A growing number of companies, however, are prohibiting remote access by employees.
- Cloud adoption slowing: According to the study, about 70 percent of companies are migrating data to the cloud—a number consistent with the previous year—but fewer companies are moving systems or servers to the cloud. More than four out of five respondents agreed that the cloud creates unique cybersecurity concerns, and only 43 percent indicated plans to move systems or servers to the cloud.
What sorts of unique security concerns does the cloud bring? According to the survey respondents, there are a variety of potential issues, such as:
- losing visibility into the management of data
- being at the mercy of the cloud provider’s security skills
- reduced control over access to data; and
- confusion about the privacy/legal issues when a government or law enforcement agency wants to access data.
In a nutshell, none of this is really new or different. Compliance, insider threats, BYOD and concerns over security and privacy in the cloud have been prevalent factors in network and computer security for years—and likely will continue to be for years to come. What has changed, though, is the focus on ways to implement better security and the tools to do it.

One of the primary issues with traditional computer and network security is that it’s reactionary. Scans provide moment-in-time confirmation that there are no known threats, but do little or nothing to protect against unknown threats or prevent exploits and compromises between scans. DevOps, and continuous security, change the game by enabling organizations to monitor for and detect security issues on a consistent, proactive basis.

“Security practitioners cannot continue to rely on manual, human controlled processes to defend against attacks,” agreed Andrew Storms, VP of Security Services for New Context. “Automation is a requirement for the next evolutionary phase of security protection.”

Nick Galbreath, founder and CTO of Signal Sciences, also believes that automation and continuous DevOps principles are key components of effective security. “I have argued that continuous deployment (how rapid the ‘continuous’ is up to the organization and risk-dependent on the nature of the code) is actually the most important security tool since without it, I don’t really know how you make things better rapidly.”

There are a lot of names tossed around for various aspects of DevOps automation. The actual name is not as important as the actual practice of proactively automating security processes for more effective security. Take a look at the report from Nuix to learn more about the general state of data security, but make sure you embrace DevOps and continuous security if you really want to do something about it.
January 4, 2016
DevOps Security: Five steps to bridging the gap between teams
Enterprise security and DevOps teams have traditionally operated separately with little to no engagement, often making it difficult to quickly identify and respond to potential vulnerabilities in applications and software. In my last column, I highlighted the value of introducing security to the DevOps process to reduce bugs and vulnerabilities before code hits production. By moving security as close as possible to the code and data, coupled with tight feedback loops, organizations will be in a better position to support the growing complexity of building software.

DevOps emphasizes an agile infrastructure that can change rapidly as new code is deployed, making it a breeding ground for bugs and vulnerabilities when security isn’t taken into consideration. So how do you close the DevOpsSec gap within your organization? The secret is to start simple, take small steps and earn easy wins. Below are five tips:
1. Build a development team that cares about its code in production. Your developers must care about their code during development when they’re writing it, when adding new features, how it performs in production and when they create fixes for issues. The team should have complete ownership of the code, what I like to call “code love,” and be able to defend it as if it were their child.
2. Implement peer code reviews. The initial way to encourage “code love” is through peer code reviews, which allow developers see what others are writing, encourages them to work together and fosters discussions among the team on how to improve processes. Additionally, with these review processes, teams will be able to identify bad practices early on and improve them.
3. Introduce a test-driven development environment. Test-driven development environments mean reproducible testing and can then leverage a continuous integration (CI) server to encourage the team to run security tests every time code is submitted. Many organizations inconsistently do this, don’t do it well or bypass this step entirely. By having developers do more testing and reviews, you can more tightly integrate DevOps and security within the organization.
4. Extend the automation. Once establishing the above, it’s time to extend the automation. Encourage your team to do code style and quality testing, which are additional tools to automate “code love”. Good clean code that is easy to read will always have fewer bugs. Additionally, introduce static security analysis to your CI server to help identify low hanging fruit and early-on implementation issues. Another option is to introduce abuse cases by having your team write malicious user stories. These are a great way to ensure the same issues don’t regress, and simultaneously serve as training material for new team members.
5. Build firefighting teams. To ensure that everyone across the board cares about this process, pull members of the DevOps and security team and put them on-call together on a weekly basis. This collaboration will allow each team member to see the issues other teams face and how their needs overlap, building a deeper understanding of each others’ roles and processes. After “code love,” this is the second most important feedback loop you can introduce to your organization.
To successfully initiate DevOpsSec within an organization, developers need to have clear parameters to work within to include the security team in the software development lifecycle (SDLC). By breaking down organizational silos and encouraging the cross-pollination of DevOps and security teams, they’ll be able to gain a better understanding of the issues they each deal with and naturally introduce joint solutions.
December 22, 2015
Why do you need to implement a DevOpsSec team?

Just 20 years ago, organizations relied on a single wall of defense to secure their applications and networks. Fast forward to 2015 and that large fence is no longer adequate. With the proliferation of mobile, cloud and SaaS technology adding to the complexity of ever-advancing systems and networks, it becomes much more important that teams across an organization work together as one, toward a common goal. We’ve already seen enterprises adopting new methods of organizing internal structures to increase collaboration through DevOps, but as security continues to be top of mind for organizations, many are looking to further this approach by including the security team in the DevOps conversation. With a DevOpsSec team, organizations can work toward delivering software that is not just reliable, but also secure.

Introducing security to DevOps provides the means to this protection by reducing the number of bugs and vulnerabilities during the build process before code hits production systems. Moving security as close as possible to the code and data will bring a large number of high value benefits to an organization.

The first benefit of introducing security to DevOps is the enablement of team collaboration through tight feedback loops. Development, operations and security teams all have different goals and are motivated by different things, which are often contrary to the other teams. To ensure that these groups don’t work as adversaries within an organization, DevOpsSec encourages them to work together, pulling from all parties’ strengths and building a collaborative and engaging environment. This collaboration offers transparency into the assorted issues that arise within each team, establishing a deeper level of understanding and respect across the board.

The second benefit is that DevOpsSec provides a wider perspective across previously siloed teams. As a result of greater team collaboration, Dev, Ops and Sec teams are able to gain more insight into how the other teams operate. This widened perspective decreases friction between them, further revealing common goals and generating more natural solutions. Overall, the assortment of perspectives results in more efficient strategies for the organization in keeping its systems secure.

Lastly, the implementation of DevOpsSec ensures faster response time to issues. As applications and systems become more distributed and complex, it becomes more difficult to identify and fix bugs and vulnerabilities. Developers are writing and pushing code faster than ever before, and what used to be monthly or longer release cycles can now be measured in hours. This is due in part to the fact that code is being used both inside and outside our networks, requiring more thorough network security. The new normal will be found in developing DevOpsSec teams and moving the security as close as possible to the code and data. Through more continuous review processes and more ownership over code in production, the merging of DevOpsSec can mean faster times in closing feedback loops and will ultimately help organizations to operate more efficiently.

So what will an organization look like after implementing DevOpsSec? As a result of the cross pollination between teams, organizations will have curated an elevated platform for innovative ideas, gained greater insights across teams and developed faster response times to help the business run smoother. With DevOpsSec in affect, organizations will better understand and anticipate security issues and the decisions required to diminish them.

December 17, 2015
Making the Case for Secure, Defect-Tested Software Development

Creating a software security initiative in any organization is no easy feat. Often times, organizational culture or politics can provide development managers with a strong counterargument for implementing software security concepts. Unfortunately, building software without a consideration for security has become a less viable option given the increase in compliance pressures and widely publicized data breaches leading software consumers to expect more security from developers.

There is no way around the fact that attacks have become increasingly more sophisticated and applications have become the central avenue of these attacks. As a result, organizations are increasingly confronted with the task of assuring secure, defect free, software development. Leaders within these organizations are finally coming to realize that vulnerable and defect rampant software undermines the productivity, privacy and security of their businesses, employees and consumers alike.

As organizations are beginning to accept the fact that there is a need to test for best practices and defects throughout the development lifecycle, it is important that they are provided with the resources to make this happen. To change the way large organizations build software, an enterprise-wide initiative is required. At its core, an initiative to change the way an organization tests and validates its development processes and practices are a fundamental business process improvement effort.

Typically, large organizations with unique operational requirements find themselves building custom software systems to address their specific needs. But building custom software on time, on budget, and without bugs is difficult. Building software that also complies with an organization’s software security policies presents an even more difficult challenge. Although the tools and practices to build secure software are maturing, most organizations find internal hurdles to be more daunting. Organizational impediments including culture, differing software development approaches, and short-term business drivers make it more difficult to effect meaningful change. In order for a software security initiative to be successful, organizations must take a phased approach that considers organizational culture at each step.

Sure, there is the option of treating the symptoms by deploying web application firewalls or running an automated scanner against applications, but this does not get to the root cause and solve the problem for most organizations. It highlights that there must be deeper process improvements involving the systems development life cycle, particularly for higher level business logic or authorization vulnerabilities.

Despite the hurdles that exist when approaching the issue of secure development, most organizations do realize that there is a problem that needs to be addressed. Organizations focus on technical means to write more secure code and strategies for putting controls around the software. The next step is to then educate executives on the process of leading a software security initiative as these initiatives are most likely to fail due to organizational issues, not technical issues. This means taking a disciplined approach by characterizing the landscape, securing champions, defining standards and strategy, executing, and then sustain the effort. These steps, tailored to the way an organization operates, will help ensure that corporate-wide efforts to secure applications are as productive as possible.

So in conclusion, it is not an impossible feat to address security at the root cause, software development, as part of standard operating procedure. It just takes a little forward thinking to demonstrate its undeniable value and get the corporate buy-in needed to change the development culture. That being said, once the culture is changed don’t rest on your laurels. Always observe what’s occurring within your organization to determine whether there are new technology risk areas emerging. If you simply focus only on well trodden areas like web applications, you may find yourself behind the 8-ball once again when it comes to new advances in software development, like mobile and the Internet of Things.

December 16, 2015
A DevOps Coders Time Allocation

Here are some other ROELBOB’s you might like

A Unit Testing Dillema

The Pink Slip

Another Pink Slip

Hot off the Press – Other great devopsy.kinsta.cloud content

DevOpsSec: 1 in 16 Chances

CIOs Must Fight for Relevance in Face of Tech Storms

Upcoming devopsy.kinsta.cloud Events

Webinar: SecDevOps: The Marriage of SecOps and DevOps

— ROELBOB

December 10, 2015
Getting Rugged DevOps Right
Two Perspectives

Jack, an accomplished application security pro, tells me, “The developers won’t talk to us. It’s like we speak a different language. They are releasing new builds so fast, how could they check each one for security vulnerabilities? We can’t move as fast as they do.”

Then in the next moment, Diane, a DevOps pro, let’s me know, “Our current security team’s tools and practices can’t keep up with the pace we have now established. If it doesn’t fit, it doesn’t get done here.”

I have heard this little ditty ‘bout Jack & Diane so often in the past two years, it could be a hit record. I imagine you have heard it too.

The Slow Lane Won’t Lead to Rugged DevOps

Let’s visit Jack’s world, first.

When visiting a well-known bank last month, they shared insight on their current application security practice. They have 10 full-time people employed (offshore where personnel costs are lower) to analyze a set of 100 applications. The bank has over 2000 applications, but the security practice can’t scale to access their entire portfolio. In 2.5 years, they had only been able to cover 5% of the application portfolio.

The application security team employs an application security tool originally built for waterfall-centric development timelines. As much as they want it and need it to move faster, it is not really for “continuous” velocity.

Each scan of an application can require anywhere from four hours to two days to get an assessment report. The reports average about 30,000 potential defects which then require further analysis. That analysis may take up to two weeks in order to sift through thousands of false-positives and false-negatives. While this security practice is critical to the bank, it cannot keep pace with development practices that are aiming to go much faster in order for the bank to remain competitive in their industry.

The Continuous Gap

Sound familiar? It should. This scenario is playing out all across the DevOps and Continuous Delivery landscape. It is reflective of what I call “The Continuous Gap”.

Leaders in Rugged DevOps practices aim to minimize the “Continuous Gap”.

In Diane’s world, DevOps teams pursue “shift left” strategies in an effort to build quality in from the beginning. Shifting left enables them to bake in the right code, components, configurations, and practices from the beginning. When done right, velocity increases dramatically, while operating costs are minimized, and unplanned/unscheduled work is reduced. Investments can then shift more in favor of innovation over upkeep and maintenance.

The Old-School Rub

Jack’s world of traditional application security practices often wait to check for security vulnerabilities at testing or release stages of the SDLC. There are two reasons for this: (1) some security tests like static or dynamic analysis can take hours or days to perform and (2) security teams cannot embed themselves earlier in the SDLC (due to political, organizational, or operational obstacles) without dramatically slowing development in a high velocity world.

If you are using old-school application security tools, you will continue to be blocked from getting more deeply entrenched in development. New velocity requirements call for new approaches.

The New-School Shifts Left

A number of newer application security solutions and practices been introduced recently that are development and developer-centric. For example, imagine if build managers could analyze every open source component used in every build for known security vulnerabilities.

What if, developers could access information inside their IDE that would inform them if a component they were planning to use in an application was known to be vulnerable? What if developers had access to spell-check like alerts of security issues as they were creating their code?

Furthermore, imagine if information was available that not only told the developer of a known security defect, but directed them to an alternative safer version of that component to use. Components would be automatically vetted against corporate security policies at the instant they were chosen by a developer. When 90% of an application is composed of open source and third party components today, automatic analysis early in the lifecycle save millions of dollars. This how Rugged DevOps rolls. This is Diane’s world.

The evolution of Rugged DevOps is forcing application security practices to shift left.

But Diane’s world (and your’s for that matter) are not just about increasing velocity. All organizations need to consider operational costs to both detect and remediate security vulnerabilities in their applications. We all realize that the further along we are in the application development lifecycle the more costly fixes become. Feel free to apply your own cost figures to the chart below, but you should also note that these calculations do not include breach cost, help desk calls, maintenance, time-to-market, reputation or stock price.

Cost considerations for Rugged DevOps practices compared to waterfall approaches.

Rugged DevOps: Shifting Gears…Quickly

Shifting from old-school to new school approaches doesn’t take long. On a recent visit to one of the largest insurance companies in North America, they shared their tale of transition. Of five major applications that run their business, one in particular had 40,000 different files that needed to be analyzed. Their old-school approach involved a lot of manual code investigation and required about two-and-a-half weeks to complete the analysis of that large application. The new approach that used automated analysis of security vulnerabilities took two minutes — and produced identical results.

A government tax office wanting to shift security analysis of applications from hours (outside of development – Jack’s world) to seconds (inside of development – Diane’s world) was able to complete the first pass analysis of their existing portfolio of 600 applications within two working days. The security team was not only faster at identifying known security vulnerabilities in applications, but could also quickly identify alternative open source and third-party software components that were safer to use. The security team was not simply discovering issues, but the new class of Rugged DevOps solutions were aiding in guided remediation.

Questions to Ask About That Rugged DevOps Solution

There are several companies and open source projects that now offer application security solutions that work at extremely high velocity. When exploring solutions to match the velocity of your Rugged DevOps practices, consider asking the following questions:
1. How long does it take to complete the analysis of a small, medium, and large application?
2. Do developers use these tools, or are they only meant for security personnel? Do you have members of development teams that act as positive references for your tool?
3. Does the analysis require further investigation of the findings, or does it pinpoint the root cause of the issue?
4. Does the solution only identify vulnerabilities or does it help guide remediation of issues?
5. What is the balance of false positives to positive alerts generated by the solution?
6. How many people are employed to support the solution in environments similar to ours?
December 10, 2015
DevOpsSec: Survival is Not Mandatory

Deming, the patron saint of DevOps once advised, “It is not necessary to change. Survival is not mandatory.”

To survive, application development teams are constantly pressured to deliver software even faster. But fast is not enough. The best organizations realize that security, quality and integrity at velocity are mandatory for survival. Hence, DevOpsSec

My aim here is to leave you uncomfortably amazed. While the pace of development has changed significantly, our processes to secure our applications has not changed enough. It is as if a wildfire has raged uncontained for years now but we have failed to take notice.

Maybe that sounds a bit crazy, but once I share a little background on what is happening, you’ll understand why innovation in this arena is critical for survival (when it comes to your applications). If you are aiming to ramp up your own Rugged DevOps or DevOpsSec practices, this is critical reading material.

Skyrocketing Usage, Plummeting Visibility

Open source component use in development is skyrocketing, and for good reason. Over 17 billion open source and third-party components — across the major development languages — were downloaded last year helping development teams accelerate release timelines and deliver more innovative solutions to market. To better imagine the impact of this download volume, you need to understand that there are an estimated 11 million developers responsible for the billions of downloads.

While the magnitude of usage is amazing it has obscured a vast majority of the risks. Of the billions of downloads recorded last year, 1 in 16 components downloaded had known security vulnerabilities.

While we have seen 30x growth of download requests over the past seven years, we have also witnessed huge growth in the number of organizations improving the speed of consumption and efficiency of their downloads using repository managers.

In the past 18 months since I joined Sonatype, we have seen active instances of repository managers like Nexus, Artifactory, and Archiva grow from 40,000 to over 70,000 installations, with users in the millions — also for good reason. Development teams want to ensure faster, more reliable builds. They also need a private and safe place to house and share their own proprietary components as well as assembled applications, images and other binary outputs. The repository manager has established itself as a parts warehouse for software development.

All is Not Moonlight and Roses

1 in 16 may not sound like a lot until you recognize that many organizations are downloading over 250,000 components every year…some of the largest organizations consume millions of them. If you have not calculated this in your head yet: 250,000 / 16 = 15,625.

Couple this fact with the remarks in the 2015 Verizon Data Breach and Investigations Report stating that applications were the most often exploited attack vector by hackers. As a developer community we are electively sourcing known vulnerable components for use in our applications and those applications are now more vulnerable to attack.

Your Repository Manager Should Serve and Protect

If bad components are getting in, why not just stop them at the front door?

Easier said than done. Current approaches to preventing such behavior are ineffective. For some, “golden repositories” are used to house approved components — but components approved once are rarely vetted again for newly discovered vulnerabilities. For other organizations, OSS Review Boards mandate reviews and approval for all new components — but these organizations are poorly staffed to match the volume and velocity of consumption leading to workarounds by development teams. And while developers themselves would much prefer to use the best quality, highest integrity components when designing an applications, they are never allocated sufficient time to investigate the vulnerability status of every component required for their latest build.

Sparking Innovation

When current approaches fail, inspiration often sparks innovation.

Enter, a new invention: a repository firewall. Think of it as a repository manager with a guard at the front door. Every component that gets downloaded by a proxy repository is automatically evaluated against the parameters development, governance and security teams establish. Does it have an AGPL license, include a known security vulnerability, or is it incredibly outdated? The repository firewall allows organizations to download “good” components while it blocks and quarantines “bad” component downloads. Using a repository firewall can keep your repository manager and development lifecycle safe and secure – in an instant, automatically.

The first repository firewall of its kind is called Nexus Firewall. It couples software supply chain intelligence about component quality, security, and risks with automatic evaluations against personalized policies for approving or rejecting new downloads. Evaluations can also be applied later in the development lifecycle where staging repositories are in use.

Imagine the result: 16 out of 16 downloads, or 250,000 out of 250,000 downloads are now of the best quality. Everything flowing into your application development lifecycle contains the highest quality components. You are instantly compliant with established policies. Your applications are less vulnerable to attacks. You are automatically reducing risk.

Next up in this series, I will share insights about Repository Health Check reports (free to use). Used by over 15,000 organizations, they can offer organizations the first clue as to whether or not your team could benefit from a repository firewall.

December 8, 2015