devopsy.kinsta.cloud

Tag: security

  • Integrating Security into DevOps: The Benefits and Drawbacks

    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

  • DevSecOps: If You Build It, They Will Come

    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.

    GettyImages-509936368

    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

  • DevSecOps: How Security Teams Can Better Support Their Developer Counterparts

    DevSecOps: How Security Teams Can Better Support Their Developer Counterparts

    Much of the conversation around digital transformation revolves around technology. But the new wave of technology this era has ushered in has also made a big impact on the way organizations, and the teams that comprise them, function.

    This impact on corporate culture has paved the way for the widespread adoption of DevOps, which has broken down silos between developer, quality and operations teams and streamlined the software development process. The next step? Integrating the security team to ensure teams are shipping software that’s actually secure.

    Here are a few ways security teams can better support their developer counterparts:

    Understand How Software is Being Made

    Development teams are under increasing pressure to ship software fast and frequently. Security teams should identify ways to help developers keep up with the rapid software development life cycle (SDLC), while making sure security isn’t sacrificed for the sake of efficiency. Understanding the SDLC for your company is key to finding ways to help that make sense. Have discussions with your development leaders and influential developers to find some ways to win. Create a pilot program with a friendly development team and pour all of your effort into making them successful. Nothing breeds success like success.

    Act as Consultants and Partners

    Developers are taking on more responsibility when it comes to the security of the code they write, which has alleviated some of the pressure put on the security team to secure an entire organization. This has changed the way security teams function and given security professionals the opportunity to act as consultants to their peers in other departments.

    Security team members should approach their developer counterparts with an attitude of enablement. Offering security best practices, problem-solving strategy and general advice will help developers become more confident in their ability to secure the software they build.

    Base all of the above on the security problems they actually have. Don’t preach. Use data from your own application scanning to tailor training. Fill a room with pizzas and developers and talk to them over lunch about problems you can help them fix. Make it conversational. Ask them how they would like to be helped.

    Embrace Ongoing Learning

    Developers have a lot to learn from their security counterparts, but developers can teach security professionals a few things, too. Setting up peer-sharing sessions where both groups can learn from each other will foster an environment of collaboration within the enterprise. Security teams can share threats related to code and specific programming languages and help developers think more like hackers. Developers can share insight into the SDLC and best practices for using code components.

    Combined, the security and development teams should also request support from the leadership team in offering additional educational resources and training.

    Breaking down the silos between development, quality, security and operations to create a true DevSecOps culture will take adjusting on all sides, and it all starts with people. Highlighting the benefit of working together (increased security, streamlined processes and ultimately a better product) is the best motivator.

    — Pete Chestna

  • Chef Advances Compliance Automation

    Chef Advances Compliance Automation

    Chef today expanded the reach of its InSpec platform for automating compliance management with an update that adds support for Amazon Web Services (AWS) and Microsoft Azure public clouds, as well as integration with additional third-party tools. In total, InSpec 2.0 adds more than 30 additional capabilities, including support for Docker containers, Microsoft IIS and NGINX web server and PostgreSQL databases software.

    In addition, InSpec results now can be exported as JUnit format for integration into continuous delivery tools such as Jenkins. Compliance profiles can now also be pulled from Chef Automate.

    Plus, InSpec 2.0 runs 90 percent faster than InSpec 1.0 on Windows and 30 percent faster on Linux, according to Chef.

    Julian Dunn, director of product marketing for Chef, said the primary goal of InSpec is to enable DevSecOps teams to address compliance issues before an application gets deployed in a production environment. It’s not feasible for any DevSecOps teams to remember all the compliance requirements that must be applied when any piece of software or hardware should be configured, Dunn said.

    InSpec provides a mechanism to automate compliance management using a set of declarative tools that don’t require anyone on the IT team to possess programming skills. Dunn conceded it’s still early on in terms of incorporating compliance into any DevSecOps initiative, most of which are nascent efforts themselves. But it’s now only a matter of time before compliance shifts left along with security, Dunn noted.

    Security becomes even more pronounced in the age of the cloud because developers are now routinely deploying workloads on top of infrastructure that is not often managed by an internal IT operations teams, Dunn said. In fact, there have been a recent raft of security breaches stemming from the fact that data was left exposed on a public cloud such as AWS.

    There’s always been a fierce debate concerning the degree to which compliance encourages security. Advocates say that without some basic compliance requirement, the level of security inside most organizations would be more abject than it already is. Others contend that compliance requirements only encourage organizations to implement the bare minimum of security required; thereby creating a false sense of security that cybercriminals easily exploit. Regardless of viewpoint, however, compliance requirements are not going away anytime soon. In fact, major security breaches usually are not accompanied by hefty fines that are based on the number of compliance requirements that were ignored.

    Developers don’t always appreciate all the nuances of compliance when under pressure to deploy and update applications faster than ever. Organizations today need to find ways to enforce compliance mandates without slowing down the rate at which applications are developed. That’s simply going to impossible to achieve without increased reliance on automation. Today, unfortunately, most of what passes for compliance processes don’t begin until long after an application is deployed in production, which makes fixing those oversights once discovered a much more expensive proposition than if they were discovered much earlier in the application development life cycle.

    — Mike Vizard

  • DevOps Brings Value to Security (and Vice Versa)

    DevOps Brings Value to Security (and Vice Versa)

    Many enterprises today are implementing security solutions that can be deployed and maintained more quickly and easily, and at lower cost, using a DevOps methodology.

    Organizations applying DevOps to security are not looking at IT groups separately as the database team and the application team; rather they see everything as the delivery team. It’s also a team that works together that deliver security services for customers.

    Application, database, network and endpoint security have traditionally been segregated, and you can see how that is built into the tools. DevOps is about bringing these pieces together and integrating operations because it’s about implementing security starting at the top of the value chain—the customers. Ultimately, we look at the value we’re delivering for the customers with security and really making sure we are inserting it into the front of the pipeline. Leading DevOps shops integrate security upfront when building the next big product, feature or service for external or internal users.

    Related Content:

    DevSecOps: Putting Database Sec In DevOps

    DevOps Introduces Complexity. Really

    There are several different models of organizational structure used to insert security into the software development life cycle. Most make sure it is an integral part of everything that gets released. But the point is that it needs to be integrated. It needs to be a living part of everything an organization is doing.

    One effective choice is make sure DevOps engineers are focused on the standardization of the network and the application.

    For example, look at locks. Most of the time, developers are keeping all passwords in locks. As a DevOps team, we’re sharing locks. That means that all credentials, even credit card information, can be exposed. Before we release the features, we need to think about security and remove passwords and credit card details.
    [su_pullquote align=”right”]Security needs to be a living part of everything an organization is doing.[/su_pullquote]
    When we look at the network and the database side, we need to disable all ports, and this is important to do before releasing things. Disable all the network ports and bring all the databases into these, and open only relevant ports.

    If you are going to embed security, it’s actually cheaper, more efficient and faster to do it in the DevOps team; otherwise, you have to train engineers in application, database or network teams on security or add an expert into those teams. But, if you add the security expert into the DevOps team, you could involve fewer people or simply additional people who are cross-trained.

    When we talk about cost savings and cost reduction with our clients, we focus on two things. We look at the model that shows how the cost of finding defects goes up as the product is developed. If you can include quality from the beginning, you reduce cost of maintenance and cost of quality—that’s the first thing. The same is absolutely true of security—that’s the second thing.

    When you’ve got an integrated SRE full-stack engineer working hand in hand with the development team, they’re thinking security, operational agility and maintainability of the system from the get-go, and they’re inserting those non-functional requirements and making sure they’re adhered to across the stack.

    This method is not at the exclusion of having the application team run code tools on security on their applications. Rather, it is someone who is looking at all these pieces and making sure they’re being done correctly.

    Ultimately, we’re producing a product that is not only functional, but actually operable in an efficient and effective way. It can’t break every minute, causing us to spend millions just to keep the darn thing alive. It works the same way with security.

    Even if it’s operable, if we get hacked, the company has a massive data breach liability.

    By having skilled engineers on the front line—particularly skilled DevOps engineers on the front line—you’ve got folks who are thinking in that full-stack mode about the security implications of the system’s operation and any issues they may see, making them more able to identify things that are potential threats.

    — Sean Mack

  • GitLab Acquires Gemnasium to Advance DevSecOps

    GitLab Acquires Gemnasium to Advance DevSecOps

    GitlLab, as part of its effort to extend the reach of its DevOps platform into the realm of security, has acquired Gemnasium, a provider of tools to mitigate vulnerabilities in open source code.

    The goal is to incorporate the IT security tools Gemnasium has developed within a single software development lifecycle (SDLC) platform, said GitLab CEO Sid Sijbrandij.

    Because both companies relied on the Ruby on Rails programming language to write their respective applications, integration of the Gemnasium software into the core GitLab platform will be easier, he said.

    Sijbrandij noted a growing number of organizations are looking to extend the reach and scope of their DevOps processes to include security, also known as DevSecOps. The pitfall they face will be trying to integrate disparate DevOps and security management tools. GitLab is moving to integrate both classes of tools within a single SDLC environment that will make it easier for organizations to make the transition to DevSecOps.

    GitLab, Sijbrandij said, already had been moving down that path prior to the acquisition of Gemnasium. Previous releases of the company’s platform have included support for static application security testing (SAST), dynamic application security yesting (DAST) and container scanning. The separate software that Gemnasium developed will no longer be supported after May 15.

    Related Content:

    How Developers Can Take a More Proactive Approach to Security

    CA Technologies Survey Uncovers DevSecOps Challenges

    Longer term, Sijbrandij said GitLab is moving toward being able to host its software on top of the open source Kubernetes container orchestration platform. That approach will make it easier to automate deployment of its software on multiple public clouds and on-premises IT environments using a zero-touch provisioning framework.

    Ultimately, embracing DevSecOps should result in more secure applications. But just as importantly, IT organizations need to be able to adroitly remediate software vulnerabilities whenever required. There’s a direct correlation between how long malware goes undiscovered and the amount of potential damage caused. It’s not uncommon these days for malware to go undetected for months; as such, eliminating as many of the vulnerabilities that cybercriminals routinely exploit must be a much higher priority for developers.

    Achieving that goal, however, is as much about process as it is tooling. Most developers are not security experts. Conversely, IT security experts typically know little about building applications. Developers are under more pressure than ever to roll out applications faster. But that pressure also often leads to them to short-shrift testing processes that otherwise would have uncovered a vulnerability. Organizations that embrace DevSecOps are trying to address security issues earlier in the process because fixing them once an application is in production is expensive. At the same time, however, no one wants to slow down the speed at which applications are being developed. That creates something of a chicken-and-egg dilemma for IT leaders trying to determine degree to which new tooling will foster changes to processes and culture, or whether they need to accomplish the latter before investing in new tooling.

    There’s always been a natural tension between developers and IT security teams. The hope is that by making them all part of the same DevSecOps team, that tension is either eliminated or sharply reduced. That outcome stands a better chance of being achieved when everyone involved is employing a common framework.

    — Mike Vizard

  • DevOps in the Cloud: Security’s Groundhog Day

    DevOps in the Cloud: Security’s Groundhog Day

    Throughout the internet age, enterprise IT has given security a lower priority than qualities such as speed-to-deployment, scalability, availability and usability. We first saw this in the late 1990s and early 2000s, when IT teams rushed applications onto the web. Amid the glee surrounding the potential of fancy new internet architectures, few thought about the possibility that these applications could become portals into the enterprise for criminals. So, the credo among development organizations was “move fast, deploy fast and seize the future.” There was no concept of risk management, beyond considerations such as availability, scalability and usability. This laid fertile soil for what would become the breach epidemic.

    As we progressed through the years, breaches became so common and massive as a result of the “web evolution” and there became a dire need to manage information security risk. Thus, enterprise security was born. As it evolved, these departments worked closely with IT management, development, infrastructure and business teams to create frameworks that aligned business goals, risk, security and agility. Security and risk management became important parts of development processes and business operations.

    Finally, there seemed to be a path forward to a more secure future … until the future changed.

    Related Content:

    How Developers Can Take a More Proactive Approach to Security

    How Blockchain Tech Can Make DevOps Better

    The future became the cloud revolution, and it plunged us back into the same festering pool of security negligence that we saw two decades ago. Indeed, when it comes to deploying applications in the cloud, security professionals likely can relate to Bill Murray’s character in “Groundhog Day.” Only in the real-life case, they repeatedly relive the same scenario regardless of what they do.

    As DevOps Teams Gain Power, Things Become Less Secure

    Since the emergence of cloud computing, enterprises once again have rushed to take advantage of a new deployment paradigm, and they are prioritizing factors such as scalability, availability and cost-containment, leaving security as an afterthought. As DevOps teams lead today’s much-ballyhooed business transformation initiatives, they gain elevated status within companies.

    Perhaps the most critical development has been DevOps teams gaining control over infrastructure, not to mention development and even corporate purse strings. While these teams follow their own best practices, their processes and protocols often don’t align with their organization’s enterprise security model. Additionally, many cloud providers increasingly are working directly with DevOps personnel, circumventing IT, security and business teams. Not only has this eradicated the interdepartmental collaboration that emerged to manage risk following the first generation of internet applications, but traditional IT and IT security processes have been disintermediated.

    The net result is that, even if a company understands the importance of security, no one team or individual is directly responsible for it because those personnel have been disintermediated. This leaves a gaping hole in enterprise cloud strategies, which is due in large part to confusion related to the shared responsibility model in cloud computing. Many organizations incorrectly assume that cloud platform security equates to application security. But, just because a cloud provider is HIPAA-compliant, for example, doesn’t mean an application deployed within that environment is as well.

    We have critical business applications exposed to a brand-new environment—and security is nowhere in sight. Companies are moving forward with cloud migration without fully understanding what their requirements should be or for what the business, IT and security teams are responsible, paving the way for a second iteration of the breach epidemic. Welcome to “Security’s Groundhog Day.” 

    Securing Cloud Migration and DevOps Processes

    We don’t have to make the same mistakes with the cloud that companies made when they first deployed web-enabled applications in-house. We can break the repetitive cycle by making security and risk management a fundamental part of cloud migration and DevOps processes. Here are a few ways to accomplish this:

    • Know your data. Everyone within your organization has a responsibility to understand what types of data are moving to the cloud on a per app basis, as well as exactly what types of controls are required to mitigate enterprise risk associated with that data.
    • Use a matrix of reference architecture to design secure-by-default solutions to meet varying workload requirements. This will help DevOps teams know when to apply more arduous requirements and when lower risk data needs fewer controls.
    • Verify your plans regularly. Agility requires compromises, and the cloud moves quickly. Without continuous monitoring and rigorous testing, you can’t be sure that what you wanted to build actually made it into production.

    Ending ‘Groundhog Day’

    Many companies are forging ahead with DevOps in the cloud without giving security a second thought, and the resulting consequences are giving other organizations pause. In the movie “Groundhog Day,” Bill Murray’s character had to re-examine his life to break the endless time loop. DevOps would be well-served to do the same: to rethink security and make it a focal point in cloud migration and processes. This is how DevOps can avoid repeating the mistakes of the past. Most importantly, there needs to be a change in the DevOps mindset.

    Security should not be the reason organizations are saying “no” to cloud adoption. When engaged as part of the process, it actually becomes the key to unlock the cloud. Making security part of the process is how you avoid “Groundhog Day”!

    — John Turner

  • CA Technologies Survey Uncovers DevSecOps Challenges

    CA Technologies Survey Uncovers DevSecOps Challenges

    When it comes to infusing security concerns into a DevOps culture, most organization still have a very long way to go. A global survey of 1,279 IT leaders conducted by the market research firm Freedom Dynamics on behalf of CA Technologies finds more than half of respondents (58 percent) cited existing culture and lack of skills as hurdles to being able to embed security testing and evaluation within software development processes. Only 24 percent strongly agreed that their organization’s culture and practices supported collaboration across development, operations and security.

    More challenging still, less than a quarter of respondents strongly agreed that senior management would sacrifice time to market to make sure there is sufficient time to assess and repair software security vulnerabilities.

    Chris Wysopal, CTO for the Veracode portfolio of security testing tools CA Technologies acquired last year, said the survey results make it clear many organizations are still wrestling with the concept of DevSecOps. Many of them may be far along the path to building a culture around DevOps, but more often than not, security teams haven’t been included in those processes, says Wysopal.

    Because security teams are not included, many organizations wind up incurring substantial costs by having to address a much broader number of security updates to applications running in production environments. Organizations that have shifted security to the left as part of more comprehensive approach to DevSecOps discover and eliminate many more security issues during the development process.

    Wysopal said the survey bears out those conclusions. The survey finds the top 34 percent of respondents who report their organizations have been able to fully integrate security into their software development life cycles view security as an enabler of new business opportunities. These organizations typically exhibited 50 percent higher profit growth and 40 percent higher revenue growth. They are also 2.6 times more likely to have security testing keep up with frequent application updates. Wysopal conceded there’s no direct correlation between better security and better overall corporate performance. But at the very least, the results indicate that organizations that invest more time in DevSecOps are not adversely impacting financial performance.

    Organizations that embrace DevSecOps not only ship higher-quality software that reduces total cost of application ownership, they also typically are in a much better position to absorb the application update impact of unexpected security events such as Spectre and Meltdown flaws being discovered in processors. Because of the need to patch these flaws, most application update processes are now being stressed across the entire IT industry.

    It remains to be seen what impact the need to quickly address these flaws will have on adoption of DevSecOps. Wysopal noted the old way of addressing security issues during a waterfall-based approach to application development simply don’t work in the age of agile development. IT security teams now need to work hand in glove with application developers. The challenge now, Wysopal said, is getting the leaders of those organizations to come to terms with the impact that change may have on the pace at which software is developed. But given the critical role software now plays in critical business processes, organizations soon will come to appreciate the need to better balance the speed of application development speed against all the potential risks involved.

    — Mike Vizard

  • Predictions for DevOps Security in 2018

    Predictions for DevOps Security in 2018

    Automation continues to be a major driver of DevOps as a whole. In 2018, we’ll continue to see a shift in how and where automation is applied in the DevOps life cycle. More specifically, DevOps will move toward adoption of integrated automation and security orchestration solutions. The need to move away from a reactive DevOps security model will see more teams integrating new solutions that leverage machine learning, analytics and orchestration that can provide incident management insights in real time. Based on that approach, here are three security predictions for DevOps in 2018.

    Continuous Response Will Become a Fundamental Part of the CI/CD Process in 2018

    DevSecOps will increasingly integrate security into the continuous integration/continuous delivery (CI/CD) process through continuous response using automation that eliminates manual processes. This continuous response as part of the CI/CD chain will go beyond ensuring that an application satisfies certain defined baseline security needs to automated threat hunting that maximizes security team response accuracy. By injecting security monitoring on the code level, continuous response can happen right from development to pre-production to the ongoing use life cycle. When this is done right, responding to security vulnerabilities becomes easier during each step of the process, reducing the time taken to fix or mitigate vulnerabilities.

    DevOps Will Transition from Reactive to Predictive Security Processes

    As market sophistication increases around cloud security, integration and incident lifecycle management, companies will become much more proactive at managing security within the DevOps life cycle. The need for integrating security orchestration into the development process rather than reacting to issues once a project has been deployed to production is clear based on the huge costs of reactive measures. As these platforms and tools become more available in 2018, companies will begin adjusting their DevSecOps mindset on both a cultural as well as products level to create a more holistic, inclusive process.

    We’ll See Solutions that Integrate RASP with Security Orchestration

    Having a comprehensive security solution for web applications with heightened detection, visibility and remediation capabilities will be key to response acceleration of web application vulnerabilities in 2018 and beyond. By extending security orchestration to web application security, developers and security teams will be capable of closing the interoperability gap. The key will be an increased visibility into the application and context of which attacks are happening by protecting web applications and API services in real time.

    Integrated solutions will enable users to design and deploy custom security rulesets based on the rich data derived from analytics to improve RASP solutions through expanded orchestration capabilities. The result will be a much-improved web application security layer capable of identifying and isolating active attackers, separating breaches from attack attempts and creating and enforcing active protection policies for better application protection. This ability to respond to escalating web-based attacks will eliminate days, weeks and months of manual tasks.

    — Rishi Bhargava

  • Moving Security Beyond SSH and PKI

    Moving Security Beyond SSH and PKI

    SSH (secure shell) is still the most common method of remotely accessing a Linux server, which makes it a common target for attackers attempting to infiltrate corporate networks. While the protocol itself carries a number of advanced security properties, it does allow for human error, opening the door for unwarranted privileged access to sensitive company resources.

    Keeping track of all valid credentials across a company is something that IT departments continually struggle with. The stakes are high if they fall into the wrong hands, essentially handing over the proverbial “keys to the kingdom.” A recent study by Dimensional Research found that 90 percent of respondents do not have a complete and accurate inventory of all SSH keys, and 63 percent don’t actively rotate keys, even when an administrator leaves the company.

    Managing privileged access to servers has always been a rigorous exercise in key management. There are a number of best practices to follow to avoid the many common pitfalls, such as storing private keys in a vault service or maintaining a strict rotation policy, but they don’t get to the crux of the matter: The credentials are static. Here’s a (not so) crazy thought: What if we got rid of them entirely? Static credentials are a thing of the past, representing the failed perimeter model of corporate security.

    Problems with Traditional PKI

    The traditional PKI (public key infrastructure) that backs SSH was built for a different time, when a key exchange meant enough to grant trust. Without a proper authentication process, there is no clear way to attribute to a person, nor a feasible way to provide any historical context. As these keys get issued and distributed across fleets of infrastructure and cloud services, the challenge only compounds. Each public key accrues more privileges over time; the longer it’s been alive, the more likely it’s been shared with a resource, making it extremely difficult to track and subsequently revoke. With this model, time is a bug that can’t be fixed.

    Authorizing a specific request should also go beyond the mere presence of the public key within the authorized_keys file of the server. Independent of authentication, authorization is about who should and should not be able to access a specific server from a known device, and what permissions they have on the machine. You may have a policy that states only members of the engineering team can only access a production server through a bastion host. Adhering to that policy in practice, however, is impossible without a proper authorization process.

    Enter Zero Trust Security

    We’ve come to a consensus across the industry that the network perimeter is breaking down in the modern cloud era. It’s time to take that one step further and agree on a new model of trust attestation to match, where decisions are removed from the network layer and handled correctly at the application layer. Flipping the model around like this means starting with zero privileges by default, and only granting access to a resource once a request has been fully authenticated and authorized. Verify, then trust—the mantra of Zero Trust.

    Google’s BeyondCorp is the marquee example of Zero Trust done right, an internal initiative meant to better secure how employees access corporate resources. The end result is a carefully crafted distributed system that makes real-time trust decisions based on what is known about a user and their device, allowing the thousands of Googlers across the globe to work securely from any location without the use of a VPN. BeyondCorp is just one example, and we’ve seen more and more companies start to adopt a similar approach.

    Ephemeral Client Certificates

    The thinking behind ephemeral credentials is that a request triggers independent authentication and authorization processes, where a trust attestation is made against the policies of the resource. If valid, a single use credential is issued, which is used to initiate a secure session with the resource. This credential is tightly scoped to the specific request, rendered useless in any other scenario.

    The fundamentals of this workflow can be accomplished through a client certificate-backed PKI architecture. Client certificates became a supported feature of OpenSSH in 2011 with the introduction of version 5.4. Unlike standard SSH keys, which carry no metadata, certificates are cryptographically verifiable metadata objects that can inject information such as usernames, roles and more. Time now becomes a feature because the scope of the credential truly represents a dynamic attestation of trust.

    The fine-grained access controls inherent in a client certificate-backed PKI architecture solves for the problems with SSH keys because the credential can be tied to an actual user. The threat vector of lost, stolen or misused credentials is also eliminated, saving managers from the numerous headaches associated with SSH key management.

    To put these ephemeral credentials into action, you need to surround the client-certificate PKI with the supporting access controls. Companies with the means can build their own system similar to Google’s BeyondCorp, but this is no simple task, as you need to operate your own Certificate Authority along with a distributed system capable of performing dynamic authentication and authorization against policies in real time.

    About the Author / Ivan Dwyer

    Ivan Dwyer is the VP of Product Marketing at ScaleFT, working with the community to raise awareness around BeyondCorp and Zero Trust for organizations of all kinds looking to modernize their security architecture. Connect with him on LinkedIn and follow him on Twitter.