devopsy.kinsta.cloud

Category: DevSecOps

Building a Solid Foundation for Microservices Security

It’s often true that threats evolve faster than development practices and technologies can keep up with, which can be seen in the current microservices approach to application development. While microservices bring clear benefits to developers by enabling application deployment via modular, independently deployable services, they also open the door to new security vulnerabilities.

Consequently, these changes in the approach to software development require a change in the mindset of developers regarding how they think about and implement security. Security now must be a core component of each service—security that can withstand the constantly changing nature of these interactive services. Each service must be a resilient and secure unit that is capable of interacting with other apps and services without compromising security. In addition, each service must be careful how it handles data at the edges to ensure every possible interaction can be secured, even when interacting with services that do not meet the required security standards.

To fully address these security challenges, developers also need to change their mindset on how they approach privacy and security in their code. That means thinking of security from the genesis of the program and from within the code itself rather than relying on the infrastructure to secure the application. This approach enables developers to start their architectural decision-making by thinking of security as the foundation of their code, instead of as an accessory.

Security from the Start

In the bigger picture, DevOps teams must have full awareness and appreciation that there is no single approach to security, and that security and privacy considerations must be addressed case by case. Although there can be more, there are essentially five things that developers can do to make microservices security foundational to the development process.

Compartmentalization

First, developers must begin compartmentalizing the software development mission by attempting to make their microservices as essential as possible. Still, developers have to be careful not to go to extremes that result in the creation of a swarm of nanoservices performing a single task. The overall goal is to reduce responsibilities to the point where each single process lacks enough information to be a liability if it were to be breached.

Encryption

The role of encryption plays prominently in the new mindset for developers, so it’s imperative to utilize it on all of the data that each microservice needs and sending it on a perishable channel. This allows the cancellation of a compromised communication channel, rotation of the encryption keys used and retrying the message on a different channel or to a different node without worrying about a breach.

A good example of this is a node where control has been lost in a high availability (HA) layout. By cancelling all message queues and resending the messages with a rotated key, it’s possible to continue functioning without worrying that the unresponsive node could be compromised and avoid a full stop.

Disposable Channel Signing

Developers will greatly improve their security posture in the software development life cycle (SDLC) by sending disposable channel signing and encrypting data to the services under their control. This will allow them to cancel credentials, and avoid data leakage, even when the control on the node is lost.

Different Keys

Developers are beginning to understand the efficacy in using as many different keys as may be needed since storage is a weak point in terms of encryption. The alternative is to use keys that are rotated regularly. This, however, requires going around the persistence solution and re-encrypting a lot of the data, which is not ideal. Besides, having layers of encryption will ensure that a single leakage from the storage keys will not grant access to plain data. Also, it’s important to use different keys for storage and transport, as re-encrypting on read is easy. This process avoids the need to spread keys and keep it tight.

Key Access

Finally, developers will benefit from making sure that all keys allow the minimum possible access while keeping in mind that they will need to tailor the time to live (TTL) as much as possible to the targeted use of each key. Although this approach may result in a complex permission schema, it delivers a massive reduction of the attack surfaces while adhering to security best practices.

Conclusion

Some of this may be common sense, and what is useful for one developer might not be sufficient for another. Generally, it’s good for developers to regularly challenge these suppositions on every service that they write, but the above formulated guidelines will serve almost every developer well by providing a stable foundation on which to begin their thinking. The universal viewpoint that they should all be taking is that security must be part of the DNA of their software.

— Horacio Duran

March 27, 2018
DevSecOps: Don’t Invest In Hope

A successful DevSecOps approach is rooted in action, not hope.

There is a lot of investment in hope.

I hope we won’t get breached.

I hope our DevOps teams aren’t deploying thousands of vulnerable containers.

I hope our developers aren’t downloading millions of vulnerable open source components.

I hope our developers and security teams will figure out how to work together.

I hope we won’t be fined under GDPR.

I hope the hackers don’t notice.

Yet, the fact remains that hope will not reduce breaches. Hope does not safeguard your containers or components. Hope cannot achieve collaboration. Hope won’t prevent a fine. Hope is not a strategy.

Many organizations are considering their approach to DevSecOps. They are moving beyond hope to strategy. They are choosing action over indifference. They are taking the first step of their journey.

Here are three ways to start your journey:

Picture This

We all learn from others. Here is a collection of 20 DevSecOps reference architectures. They reveal the choices and priorities others have made ahead of you. Look at what they did. Choose to do something similar, or create your own path from a mix of their ideas. If your canvas is blank, use these to draw something.

Watch This

The pioneers are the ones with the arrows in their backs. Another word for DevSecOps pioneers is practitioner. And many practitioners have navigated their journey successfully enough to share it. More than 15 practitioners shared the tale of their DevSecOps journey during All Day DevOps. Every session was recorded online. Every session is free. Start with this one from DJ Schleen at Aetna and then pick your next one.

Start There

In a panel discussion I sat on recently as a prelude to DevSecOps Days at this year’s RSA Conference, I heard some very practical advice (find the recording here). One of the other panelists, Stephanie Derdouri from Fannie Mae, advised our audience to start with one thing. Don’t pick a bunch of strategies and tactics. Just pick one painful, suboptimal or annoying practice tied to security and improve that element within your DevOps practice.

Pick only one. Start there.

Hope is not a strategy. Action is your only safe option. Take the first step.

— Derek E. Weeks

March 23, 2018
Barracuda Networks Survey: DevSecOps Is Hard

Organizations that have adopted DevSecOps processes may be making progress when it comes to improving cybersecurity, but it’s far from easy. A survey of 618 IT decision-makers conducted by Dimensional Research on behalf of Barracuda Networks, a provider of IT security software and appliances, finds half have adopted either DevOps, DevSecOps or a continuous integration/continuous development (CI/CD) platform. A full 93 percent of those IT decision-makers said they faced challenges integrating security into those practices.

Top challenges cited include: Existing security technologies don’t integrate with application development environments (63 percent), application developers are not comfortable with security (48 percent), and security processes have not evolved (48 percent).

Much of the frustration can be tied to reliance on firewalls that don’t feature application programming interfaces (APIs) or are natively integrated with a public cloud, said Tim Jefferson, vice president for public cloud at Barracuda Networks. Each cloud service provider has a unique environment that requires providers of IT security software to write code that natively integrates with that platform. IT organizations can’t simply cut and paste security controls created for on-premises IT environments mainly because the cloud provider has already implemented its own controls at the infrastructure level. The IT organizations need to develop their own controls for the application layer, each of which then must be layered on top of the controls put in place by the cloud service provider.

In the absence of those capabilities, developers get frustrated because a firewall running on a virtual machine on a public cloud presents them with a graphical user interface (GUI) rather than an API. Developers in the age of the cloud are not going to engage with any technology that they can’t programmatically invoke via an API, Jefferson said.

Not surprisingly then, the survey finds the most requested firewall capabilities requested are cloud-native integration (74 percent), ease of deployment and configuration by cloud developers (59 percent), ability to regulate traffic flows between on-premises IT environments and public clouds (56 percent) and distributed policy enforcement (53 percent).

Because many IT professionals don’t have these capabilities many of them conclude on-premises IT environment are more secure than public clouds. More than half the respondents (56 percent) say on-premises cybersecurity is still superior to a public cloud. Clearly, there a lot of technical and emotional factors that go into those assessments, but regardless of the truth, perception remains reality.

Regardless of the approach taken, however, organizations that deploy firewalls in the cloud are expecting to pay for those services on a consumption basis, which doesn’t always align with taking a firewall running on virtual machine and then deploying it on a public cloud.

Jefferson said that as cybersecurity in the age of the cloud continues to mature, expectations are rising regarding the capabilities a firewall should be able to provide—especially when it comes to controlling the flow of traffic coming into and out of a public cloud.

Obviously, anything to do with DevSecOps these days is still evolving. But whatever the cybersecurity future holds the relationship between on-premises and cloud security is far more nuanced than many appreciate.

— Mike Vizard

March 22, 2018
Software Liability Goes Global
This month, France turned up the conversation on software liability for manufacturers who place known defective software components in their products. But, they are not the first.

Software Liability in France

According to Lukasz Olejnik, lawmakers in France just suggested a desire to “put the security liability in hands of product suppliers. In other words, making companies responsible for the security of products they put on the market—for as long as the products are commercially available.”

He continued: “The strategy then mentions that one of the solutions could be to release source code and documentation after an end of support date. The strategy itself mentions taking this discussion to the international level. This will be interesting.”

You betcha, Lukasz.

(If you can read French, you can find the 166-page proposal here).

Software Liability in United Kingdom

The need for improved cyberhygiene in the UK reached new heights in 2017 following large-scale ransomware attacks on its nation’s hospital system and an increased focus on software liability. According to the UK’s National Cyber Security Strategy 2016-2021 report, “Businesses and organizations decide on where and how to invest in cyber security based on a cost-benefit assessment, but they are ultimately liable for the security of their data and systems. Cyber attacks are not necessarily sophisticated or inevitable and are often the result of exploited–but easily rectifiable and, often, preventable–vulnerabilities. In most cases, it continues to be the vulnerability of the victim, rather than the ingenuity of the attacker, that is the deciding factor in the success of a cyber attack.”

Shedding a spotlight on the cyberhygiene and software liability, Britain’s Information Commissioner’s Office (ICO)—the country’s data regulator, said a hacker exploited a well-known security flaw on a Gloucester City Council website months after the vulnerability had been widely reported on and updated component versions had been made available. The ICO fined the Gloucester City Council £100,000 in June 2017 for not preventing a cyberattack exploiting the OpenSSL Heartbleed vulnerability.

Software Liability in the United States

Last August, Sens. Mark R. Warner (D-VA) and Cory Gardner (R-CO), co-chairs of the Senate Cybersecurity Caucus, along with Sens. Ron Wyden (D-WA) and Steve Daines (R-MT), introduced bipartisan legislation called the Internet of Things Cybersecurity Improvement Act of 2017.

According to a fact sheet released at the time, “While ‘Internet of Things’ (IoT) devices and the data they transmit present enormous benefits to consumers, the relative insecurity of many devices presents enormous challenges. This legislation is aimed at addressing the market failure by establishing minimum security requirements for federal procurements of connected devices.”

The proposed legislation requires vendor commitments:
- To ensure devices don’t contain known security vulnerabilities when shipped;
- To ensure proper disclosure of new security vulnerabilities discovered within their devices; and
- To prepare remediation plans for any IoT device where known vulnerabilities have been discovered.
While the legislation is clearly aimed at consumer protections and privacy, it also focuses on quality, safety and regulatory standards applied to every other major manufacturing industry (thou shall not ship products with known defects). The legislation specifically calls for vendors selling IoT devices “to provide written certification that the device does not contain, at the time of submitting the proposal, any hardware, software, or firmware component with any known security vulnerabilities or defects.”

Software Liability in the European Union

When the innovation race is being run without proper oversight, getting to the finish line safely will require greater (and faster) care. That’s set to be a major challenge for organizations developing software under the forthcoming EU General Data Protection Regulation (GDPR) in May 2018.

Article 32 of the GDPR states that organizations must “implement appropriate technical and organizational measures” to “ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services.” When combined with Article 25, which mandates that data protection measures be implemented “by design and by default,” it’s clear that privacy and security must become ingrained in every element of IT infrastructure.

If you fail to follow these rules and known software vulnerabilities end up inadvertently helping hackers steal sensitive consumer data, you could be on the hook for seriously big fines: up to €20 million, or 4 percent of global annual turnover, whichever is greater.

Software Liability in Germany

In July 2017, a consumer advocacy group in Germany has filed a law suit against a retailer in Cologne that sold an inexpensive smartphone made by Mobistel. The Mobistel model Cynus T6 was sold in Media Market stores for just 99 euros. Sounds like a great deal, right? Not so much. You see, the phone’s software came with 15 critical and known security vulnerabilities that were not disclosed to the consumer at the time of purchase.

Instead, these security flaws were later identified by investigators from the Federal Office for Information Security (BSI). Unfortunately for Mobistel and Media Market, consumer advocacy groups tend to fight back when manufacturers and retailers sell products to consumers without disclosing “essential information” such as known security defects in a smartphone.

Although the complaint is at an early stage, it points to the possibility that companies manufacturing software applications could be held liable for selling defective products to consumers—in exactly the same way that auto makers have long been held liable for defective parts in cars.

Think You Aren’t Shipping Vulnerable Software?

Think again. According to Sonatype’s “2017 State of the Software Supply Chain Report,” 80 percent to 90 percent of a modern application is now assembled from open source and third-party components. Therefore, “It is incumbent upon development organizations to practice good hygiene when consuming open source components. Teams with suboptimal hygiene inevitably consume open source components with critical vulnerabilities. Last year, 5.5% (1 in 18) components downloaded from internet-based open source repositories contained known security vulnerabilities.”

What does this mean for you? If you have not been paying attention, the chance that software your organization is building contains a known software vulnerability is nearly 100 percent.

The Writing is on the Wall

Organizations failing to manage software supply chains, who are unwittingly releasing vulnerable applications into production, will face increased liability due to gross negligence.

The writing is on the wall. Are you prepared?

— Derek E. Weeks
March 21, 2018
DevSecOps: Digging into Root Cause Analysis
We have all been there in a postmortem when someone says, “Let’s get to the root of the problem.” And, we all know what that means: Who or what is to blame? We also all know that no one wants to play the blame game, yet we all do. But it isn’t our fault (no blame, see what I did there?). It has been the default system for solving problems in business for decades. It is called root cause analysis.

We can change—for the better.

I recently watched a presentation from Matthew Boeckman (@matthewboeckman) titled, “There is No Root Cause: Emergent Behavior in Complex System.” Matthew is a developer advocate with VictorOps and a technology strategist with Dryan.io. He grew up a systems guy and jokes that he has been in DevOps for 18 years, even though DevOps wasn’t around, because he has always been nice to developers.

Digging in (pun intended), root cause analysis focuses on what went wrong, and how we can prevent it from happening again.

The core problems with root cause analysis for development is that it doesn’t provide for enough complexity and its natural focus is blame, which can undermine a positive DevOps culture.

Root cause analysis was more applicable when waterfall was the development methodology because states stayed consistent for months or even years at a time. In the age of Agile, DevOps, CI/CD, microservices, etc., states of work are in a constant flux. Root cause analysis can’t provide solutions quickly enough. As Matthew notes, in root cause analysis, things are either good or bad, working or broken, uptime or failure. The reality is that our world is more nuanced.

What Matthew recommends is to look at it through the principle of emergence because it, “separates judgment from the good and the bad binary approach to our system health, and instead focuses on behaviors and interactions, patterns and complexities of our system. With practice and effort we can manage them to more desirable states.”

But what does this look like in practice?

Getting back to the analogy of the tree and its roots, the answer is more of a forest than a tree. Trees are one living organism, forests are ecosystems.

Matthew takes this philosophy and mental picture and gives us a better system: Cynefin. It is a Welsh word that means habitat, and was created by Dave Snowden (@snowded), originally for managing IBM’s intellectual capital. It draws on research in systems, complexity, network and learning theories.

Starting in the bottom right quadrant, working counter-clockwise, its goes from simple to more complex.

Simple

These are patterns or behaviors that don’t require a great deal of understanding. DevOps is increasingly setting up automated systems to respond to simple issues.

Complicated

These are known unknowns. You can imagine a set of realities where they can occur and they are probable, but not certain. For instance, a busy harbor might get a storm that causes damage to boats, docks, etc. It is hard for the harbor manager to manage and they need to think about it. This requires people to do some thinking, and it is difficult—if not impossible—to automate.

Complex

This is where we start to see emergent behaviors occur. We don’t have the metrics need to understand or manage these problems or you haven’t looked at that metric before. We start with probing, going into the system and exploring. Think of any collection of humans at any scale. Things are still in the scope of probable, but things change quickly. There are many moving parts that aren’t predictable and that we didn’t fully encounter in our test methodology.

Chaotic

This is, well, chaos. Matthews’ real-world example was when an entire region for AWS went down, causing other regions to be overloaded as system admins were moving services. In chaos, you act, then get a sense of where things are and then respond.

Disorder

In DevOps, this is where you have lack of communication and collaboration. Here teams need to: reduce: figure out what you agree on; analyze: build consensus; and, iterate: move to a quadrant and continue.

Matthew notes that knowledge and practice move patterns toward more favorable quadrants. But, complacency erodes the process. Complex systems left poorly managed will create increasingly complex processes to manage.

How to adopt Cynefin
- In the moment: Ask, what quadrant does this map to?
- In the post incident report: How did we manage the pattern? Was it complicated, complex, simple? What can we do to change it?
- In your sprint planning: Devote time to manage your patterns clockwise. What can we move with a little bit of work?
The reality is that root cause analysis is really only present after the fact. Cynefin calls us to action.

Convinced that Cynefin might be just what your organization needs or want to dig a little deeper? Share and watch Matthew’s full talk here. You can watch any of the 2017 AllDayDevOps sessions free of charge here.

— Derek E. Weeks
March 16, 2018
DevSecOps: Deception in Depth

Mantraps, tripwires and tarpits … sounds like the start of a solid spy-movie plot, doesn’t it? These are among the many concepts of physical security that are making the crossover to software security.

You’ve likely heard that security is all about defense in depth—the idea of layering several defensive measures so that their combined effectiveness is stronger than if they were used individually.

In the case of deception, we are taking tried-and-true warfare approaches and applying them to DevSecOps. According to researcher, deception specialist and popular speaker Herb Todd, there is no rule of law in warfare, and in environments where you put code on the web, you are giving the world access.

Deception Approaches

There are two primary approaches to deception in software security. The first is to get attackers to look in places where you have no vulnerabilities. Todd would call this, “Appear weak where you are strong.” This is what honeypots do: offering an attacker a weak-looking target that appears as if doors are unlocked and there’s an opportunity to gain a foothold. All the while, there is no real vulnerability to be found, and the defensive team can be alerted to an adversary on the network.

The second approach is to isolate or slow down attackers as they progress through your networks and application. One way to do this is to add tripwires throughout. When parts of your web application starts being manipulated in ways that normal users wouldn’t do, you know you have an adversary testing your application looking for vulnerabilities. At this point, you can move them off to a segmented portion of your application or network through the use of a mantrap, or slow them down with a maze or tarpit.

Provoke Action

Deception measures hinge on being able to get attackers to take an action. This is the main goal of deception. If we can provoke an action from the adversary, then we can begin to understand them and to track them throughout our system. This creates a feedback loop in DevSecOps for developers, operations and security to determine how many adversaries are currently interacting with the system, what they are attempting to do and how to add new defenses in the future.

None of the major data breaches you read about start with the organizations saying, “Our security team has been tracking these attackers for weeks.” In fact, it is the exact opposite: We usually learn that the attackers had been inside the system and exfiltrating data undetected for months on end. The organization didn’t know they were under any attack until after their database got dumped on the internet or leaked to the media.

Start with Tripwires

Deception sounds great, but how do you go about it? In Todd’s talk on the Modern Security Series, he gave several ideas on how to get started in the case of web application security development. Methods in DevSecOps include adding fake paths to robots.txt and fake hidden fields to your application. When someone hits your tripwires, you log it and fire an alert for the team to investigate. As you gain familiarity with that, moving into tarpits and mantraps begins to make more sense.

One example that Herb Todd gave in his talk was to add a hidden field of “encrypted-auth” and set it equal to “YWRtaW49ZmFsc2U=”. An astute web developer will notice that this is not actually encrypted. This is a base64 encoding of “admin=false.” When an attacker sees this, they will immediately think, “What if I tried sending admin=true?”

So the attacker takes the string “admin=true” and then uses base64 encoding to produce “YWRtaW49dHJ1ZQo=” and submits that. Now, if your application receives a value for the hidden field that isn’t the original value or matches “YWRtaW49dHJ1ZQo=”, then you have actionable intelligence to alert on.

When creating a tripwire is this simple, why stop with just one? Adding small tripwires throughout an application through DevSecOps can be highly valuable to identify more advanced attackers.

DevSecOps: Making a Practice of Deception

While deception is beginning to gain favor among AppSec professionals and thought leaders, it’s not yet standard practice by any means. But this should soon change, as the next year or two see the best security teams adopting deception strategies—and for good reason. With traditional methods such as web application firewalls (WAFs) breaking down in the face of high-volume traffic and more sophisticated threats, security needs to become more creative. Defense-in-depth concepts such as deception have been proven effective in the physical worlds of warfare and spycraft—and when incorporated into DevSecOps, they can be just as powerful for ensuring protection in the digital world as well.

— James Wickett

March 8, 2018
Malicious Intent: Open Source Developers, Please Protect Your Users

For the second time in just a few weeks we’re seeing the fallout of missteps taken by publishers of open source components. It was just recently that I wrote about the GitHub id of go-bindata being highjacked. We don’t know for certain if the intentions were malicious, but the risk was obvious.

Even more recently we find that credentials were compromised for an npm component called conventional-changelog and a malicious version was uploaded that allegedly included a Monero cyptocurrency miner. Anyone who built or installed an npm package depending on the malicious package is now potentially running a miner and worse, potentially distributing it to their downstream users or customers.

A few months ago people were laughing at a parody of a similar situation describing credit card harvesting via a compromised package. It’s not so funny anymore, is it?

Open source developers typically thrive in creating something used by millions or billions of other people. This is the fuel that drives us and knowing that you’ve contributed, even in some small part, to the lives of millions of users is amazing.

Conversely, knowing that you’ve accidentally inflicted harm on those users through careless practices is probably devastating. Yet, seemingly not enough people are thinking about this beforehand while it’s preventable.

We open source developers and package maintainers are finding ourselves at the frontline of the new battle. Attackers have recognized the power of open source in terms of broad distribution and are seeking to use that against us.

We must not let them ruin the reputation of the things we’ve built—or, worse, the entire open source ecosystem.

If you’re an open source contributor or package maintainer: Pay attention to your own digital security as you would if you were protecting millions of others. Because you are.

— Brian Fox

March 7, 2018
Security: How to Conduct an Agile Incident Postmortem

In a perfect world, every organization could block every attack, no employee would ever make a mistake, and there would be advance warning that an organization is on some cybercriminal’s list of targets. Since organizations operate in a world that is far from perfect, however, they are forced to accept that bad things will happen. History and headlines show they cannot erect enough barriers to stop cybercriminals from trying to penetrate defenses, they cannot hire perfect employees and they must assume their name has been bandied about as a potential target.

One of the things they can do, however, is use each incident as a learning opportunity by conducting a thorough postmortem. To maximize the benefits of a post-incident analysis, organizations should remember two things: agility and blamelessness.

Agility

To a developer, agility is a development methodology that provides significant benefits over the traditional waterfall method. However, agility implies a system of thinking, processing information and executing plans. As such, agility belongs in the realm of security as much as it belongs in the realm of development.

Currently, the advantages offered by agility tend to be reaped more by cybercriminals than by security professionals. The bad guys get to go first, and since they are not bound by compliance issues or regulations, have no concern for the rights of individuals and don’t have to answer to advocacy groups or government agencies, they have the advantage. Cybercriminals embrace agility to launch attacks that can change from one day to the next.

Unless security professionals are as agile as the crooks, they will be limited to reacting to incidents instead of proactively preventing them. One way to help level the playing field is to build in the ability to move quickly when an incident occurs—and this includes a plan to conduct an effective, thorough and efficient postmortem.

However, a postmortem implies that an incident is over and is now undergoing a final review. If organizations are truly agile, they will have conducted at least one retrospective prior to the postmortem. Agile retrospectives are conducted to assist the team in making immediate changes and are more about action than review.

Blamelessness

For retrospectives and postmortems to be effective, the second key is to ensure that postmortems are blameless. The end goal is to get to the truth so that organizations can better protect their operations in the future. Assigning blame can make it much more difficult to uncover the truth.

For example, if an employee clicks on a link that spreads malware throughout the corporate network, he or she might be afraid to admit the mistake for fear of being chastised privately or blamed publicly. The organization then wastes time searching for the source of the infection, instead of being able to deal with the incident immediately. Therefore, the postmortem must be blameless and cordial, with no finger-pointing allowed. Keep the focus on what happened rather than who is responsible.

Postmortem Best Practices

Understanding the two “prime directives” for conducting a postmortem, organizations have a few other considerations to help them gain the most from their post-incident evaluation. First, they need to learn precisely what happened and how it can be explained concisely, accurately and appropriately. If the chain of events is not understood, an organization will not be able to enlighten team members or non-technical employees.

Next, the incident should be used as a learning experience to ensure that the problem will not occur again. Organizations should evaluate whether the issue is a simple employee mistake, a tool on which staff members were not trained, miscommunication or a process that is broken. Everyone should be focused on preventing another occurrence, as well as ways to achieve continuous improvement.

After the facts are uncovered, an organization must take action, ignoring “should have” and “could have” statements and focusing energies on “will” and “must.” In addition, organization must establish priorities and assign follow-up actions before ending the postmortem.

Also, employees and team members should be encouraged to discuss potential issues whenever they arise. Employees may need guidance on whether an action is safe, team members may need to confess that they made a mistake or supervisors may want to discuss ways to help workers learn how to identify suspicious emails.

Trust and communication are essential if organizations want to gain the greatest benefit from their postmortem. Organizations need to stay open and approachable so they can reduce the number of incidents, improve incident response and strengthen their company’s defenses.

— Erin Swanson

March 6, 2018
Integrating Security into DevOps: The Benefits and Drawbacks
The efficiency of DevOps for your enterprise will depend on the level of security you integrate in it. The integration of security into DevOps is new to many enterprises, but is highly important because the speed of DevOps can make the apps in development vulnerable to malicious attacks. This can be prevented with the help of right security controls.

Security and development teams must understand each other’s requirements and goals. Some might view security professionals as the ones who tap the brakes as the DevOps team moves forward. However, the job of security is to manage the risk effectively. To accomplish this, the security team must be integrated into the DevOps process.

In many companies, this is a completely new methodology, and different structures are needed for different companies. The global security function is a component of the program management ecosystem by one security model. Security is integrated as an essential member of the development organization by another security model.

Blockchain is the underlying technology behind cryptocurrencies such as Bitcoin and is used to secure the bitcoin wallet. The implementation of blockchain in a company’s DevOps process increases its agility and delivery efficiency, while the integration of security benefits an organization’s DevOps process in multiple ways. However, along with these benefits, few drawbacks do exist. Let’s dig deeper into both of them.

The Benefits and Drawbacks of Integrating Security into the Program Management Ecosystem

The program management function has a significant role to play in this model. It ensures that security is in place, and confirms that all the required specifications are documented and met. Security then carries out evaluations and determines what critical issues need to be addressed. In this security model, the security office can address the condition of a wide range of products that the organization delivers in a uniform manner.

The drawback is that the issues related to security often are listed on a slide for review by executives and noted by the most important person in the development organization. Consequently, the list becomes a road map for “what we must fix” more than a prescription for “what we must make sure the product sticks to before it gets shipped.”

The Benefits and Drawbacks of Integrating Security into the Dev Organization

If the security team is a component of the development organization, they must maintain close contact with the global security office. But they can be much closer to the product development. This means they are closely working with feature teams and determining stories that should be planned into the sprints.

These assessments cannot wait until the end—they must be planned into the first sprint that makes sense. Then, the resulting group of issues becomes technical backlog to prioritize into the following sprints. The goal is to produce applications that are safe for customers and have assessments that are known and can hold up to customer audit.

However, the local security team must connect strongly to the global security office. Every security team that is a component of the development organization must rise to act as a single brain across all the products; companies cannot have any variance with respect to adherence to mandates, assessments, tools and standards.

Where to Incorporate Security?

To enable a continuous security mindset, security must be covered by automated test cases related to security in the continuous deployment/continuous integration process over the following phases:
- Regular operations – near-real-time automated enforcement and utilization of continuous monitoring.
- Integration phase – full sanity checks for external/internal endpoints, and make sure any new workloads do not break any of the security policies.
- Infrastructure creation phase – test utilizing tooling such as serverspec/rspec.
- Image creation and hardening – as part of the delivery pipeline, automate this phase.
- Build phase – utilize code analysis.
Securing QE and Dev Labs

The final dimension is quality engineering (QE) and development, though they might be forgotten. Both of them have labs in which they make sure all the functionality performs, scales and works. These labs are good targets for intrusion, and security has a major role in the remediation and evaluation of the lab environment.

Conclusion

Adopting a DevOps methodology can instigate security vulnerabilities and new blind spots introduced by new systems. But fewer workplace silos and improved communication can help address issues much quicker. Today, security also can be integrated into DevOps using various technologies. It is highly essential to have security integrated into the process, no matter what method works best for your company.

— savaramravindra
March 1, 2018
DevSecOps: If You Build It, They Will Come
Spring training for Major League Baseball in the United States has begun. Millions of people share my love for baseball; however, the same can’t be said for security and compliance—well, at least not yet. Perhaps one day.

Much like in the immortal baseball movie, “Field of Dreams,” if you build a friendly security and compliance system, the developers and operators will come. At least, that is the contention of Julie Tsai (@446688), senior director of security operations at Box.

I first met Julie at the RSA conference’s DevSecOps Days three years ago and have been following her musings since. I recently watched Julie’s presentation, “Build It and They Will Come-pliant: DevSecOps in the Real World,” from All Day DevOps. Here is a summary of what I learned:

Good Architecture Sustains Sound Applications and Security

Julie’s contention is that you can build a system that might actually bring a little joy to developers and operators, and it starts with realizing that, at the end of the day, we are all looking for good architecture. Good architecture sustains sound applications and security. It makes everyone’s life easier, so we all have a little time for baseball (or football or board games or even curling).

The good news is that DevOps organizations are ahead of the game. Julie pointed out the old joke, “DevOps … isn’t that just where you give the keys to the developers?” Well, no, and it isn’t a specific tool or deployment. For security, it is about being lean on requirements, building compliance in from the start and integrating it across the development life cycle so you can build something that is secure and performant. Besides these being best practices for developers, they also allow you to use your code and policies to appease your auditors, as compliance is built-in. Bottom line: DevOps puts the rigor around security and compliance.

It Takes a DevSecOps Village

Julie pointed out a couple of takeaways from DevOps that help security and compliance:
1. You can own a problem and be an individual leader. You can think globally but act locally by seeing across the silos and bringing a message of empowerment.
2. It provides a path toward integration to internalize other groups’ values, bring them into your own words and ways and mutually reinforce and thrive. It also informs how people work together.
Remove Friction to Scale DevSecOps

The goal here is to ultimately get us something easier to scale and maintain and be compliant and secure. Julie outlines steps to get you closer to this idyllic system:
1. Use configuration management because it leads to precision and more unified and verifiable work.
2. Get rid of whatever you can to eliminate mistake factors. You will also get to a place to streamline workflow so there are fewer mistakes.
3. Extend infrastructure as code. It can become configuration as policy and your audit trail can connect the intent to the execution.
DevSecOps: Where Things Go Wrong

With these in place, Julie contends you need to realize the world isn’t perfect, so you need to build a system that injects security and compliance where it is most effective. To find the areas in the development life cycle that it is important to inject, ask these questions:
1. Where is someone intending to make a change?
2. When you are releasing it live into your production stack?
3. What is happening when something isn’t going as expected? Is it being changed back to where you need it to be, are you monitoring it, or are you doing nothing?
DevSecOps: String Together Wins

You also need to make it simple. She quoted Mark Burgess, “IT has a detail sickness,” noting that, “We are often burdened by complexity—we love it and dig right in, but it is important to understand the level of granularity you need. You need to look for the things that can make a critical uplift that gives you an incremental improvement. String together the wins.”

In the end, Julie said to “try to reach a goal of being visible and streamlined and leverage the automation and technology in a way that is joyful in how we use it. It is not about a rigid process that is going to die soon; it is about what we are trying to bring to the whole world so that we work more efficiently and more technical.”

The entirety of Julie’s presentation—including some live Q&A—is available here. If you missed any of the other 100 speakers at All Day DevOps, you can find their 30-minute presentations here.

— Derek E. Weeks
February 28, 2018