devopsy.kinsta.cloud

Category: DevSecOps

  • Google Advances Confidential Computing

    Google Advances Confidential Computing

    Google has kicked off an effort to make it easier to build secure applications using an open source framework for confidential computing, which enables encrypted data to be processed inline by an application without ever requiring the data to be decrypted.

    Asylo is an open-source framework and SDK for developing applications that run in multiple instances of these trusted execution environments (TEEs), said Rob Sadowski, Google Cloud Trust and security marketing lead. TEEs are designed to prevent cyberattacks targeting operating systems, hypervisors, drivers and firmware.

    Asylo makes it possible for developers to build confidential computing applications that can be ported across multiple types of processors. Version 0.2 of Asylo will offer an SDK and tools to help developers create portable enclave applications. In the future, Google plans to provide the ability to run existing applications in a TEE using an Asylo container. Asylo will be compatible with the Kubernetes container orchestration engine and the Istio services mesh, which Google has played a leading role in developing.

    Multiple processors have extended their instruction sets to enable confidential computing, but developers have been required to master the nuances of each of those extensions. Each application also winds up being locked into those extensions. Google is working to ensure Asylo will be compatible with AMD Secure Encryption Virtualization (SEV) technology, Intel Software Guard Extensions (Intel SGX) and other similar extensions to hardware platforms.

    Sadowski said an open source framework that makes it easier to build secure applications also represents a significant advancement for DevSecOps. Today, constructing confidential computing applications is simply too painstaking and time-consuming for most developers to master. A framework for building secure applications provides a high level of abstraction that is easier to master.

    Google is not recommending that every application going forward should include confidential computing functions. There are still significant application performance trade-offs to be considered. But there is an increasing number of applications in which data security issues will trump those performance concerns.

    Most developers don’t set out to build insecure applications. Arguably, IT vendors have simply made it too difficult. A framework that enables applications that run in TEEs to be built more easily is likely to be received well by developers and cybersecurity professionals alike, as cybercriminals are taking advantage of advanced vulnerability scanning tools to identify potential exploits up and down the entire computing stack, including unpatched operating systems and firmware.

    It’s too early to say how much mainstream adoption of confidential computing there will be. Most of its usage has been limited to government agencies and financial services organizations that have enough budget dollars to build, maintain and run these applications. Asylo should go a long way toward making TEEs more accessible to the average developer in a way that should lift much of the burden put on DevSecOps teams, who today struggle to secure data strewn across the extended enterprise.

    — Mike Vizard

  • Reducing Risk in Applications Using Docker Containers

    Reducing Risk in Applications Using Docker Containers

    Docker. It seems like in this day and age you are either using Docker containers or you are going to use Docker containers. If you haven’t jumped on the bandwagon yet, check out a previous article, “Docker: The New Ordinary.” If you are on the wagon or are thinking about it but have concerns about their security, it’s time to read on.

    José Manuel Ortega (jmortega.github.io ) is a software engineer and security researcher in Spain. I recently watched his presentation online titled, “Testing Docker Images Security.” He gave an overview of typical Docker deployments, explained the attack surface and threats, presented how to detect vulnerabilities and outlined a couple of best practices. In short, his advice will help you learn how to better secure your Docker containers.

    (New to Docker? Read this paragraph; all others skip ahead.)  If you aren’t sure what Docker is, José offered this explanation: “Docker containers wrap a piece of software in a complete file system that contains everything it needs to run: code, runtime, system tools, system libraries—anything you can install on a server, regardless of the environment it is running in.”

    That is, containers are isolated but share an operating system and, where appropriate, binaries and libraries. Docker provides an additional layer of isolation, making your infrastructure safer by default. This makes the application life cycle faster and easier to configure, reducing risks in your applications.

    For starters, José laid out Docker’s default mechanisms for security:

    • Linux kernel namespaces
    • Linux Control Groups (cgroups)
    • The Docker daemon
    • Linux capabilities (libcap)
    • Linux security mechanisms like AppArmor or SELinux

     

    Screen Shot 2018-04-08 at 7.17.58 AM

    José walked through others tools, add-ons, best practices, etc., to increase Docker container security. I will cover most of them here.

    Docker Inspect Tool. The Docker Inspect Tool is built into Docker. It provides information about the host name, the ID of the image, etc. and it comes up when you start Docker.

    Docker Content Trust. It protects against untrusted images. It can enable signing checks on every managed host, guarantee integrity of your images when pulled and provide trust from publisher to consumer.

    Screen Shot 2018-04-08 at 7.19.01 AM

    Docker File Security. Docker files build Docker containers. They should not write secrets, such as users and passwords. You should remove unnecessary setuid and setgid permissions, download packages securely using GPG and certificates, and try to restrict an image or container to one service.

    Container Security. Docker security is about limiting and controlling the attack surface on the kernel. Don’t run your applications as root in containers, and create specific users for testing and policing the Docker image. Run filesystems as read-only so attackers can not overwrite data or save malicious scripts to the image.

    José provided a useful checklist to check the security of a Docker container, but it’s not a short one. Remember, if you are going to deploy hundreds or thousands of these containers, you’ll want to ensure consistent handling of security concerns to keep the hackers at bay:

      • Do not write secrets to Docker files
      • Create a user
      • Follow version pinning for base images, packages, etc.
      • Remove unnecessary setuid, setgid permissions
      • Do not write any kind of update instructions alone in a Docker file
      • Download packages securely
      • Do not download unnecessary packages
      • Use COPY instead of ADD
      • Use the HEALTHCHECK command
      • Use gosu instead of sudo whenever possible
      • Use no-cache (if applicable) when building
      • Enable Docker Content Trust
      • Ensure images are free from known vulnerabilities
      • Ensure images are scanned frequently throughout your DevOps pipeline
      • Ensure your images, packages are up to date
      • Use file monitoring solutions for image layers (if required)

    Auditing Docker Images. You can scan your images for known vulnerabilities with a wide variety of commercial and open source tools such as:

     

    All of these solutions can be integrated in one element of your CI/CD pipelines — some can be integrated in multiple places.

    José explored these solutions and best practices in more detail and offered up technical implementation tips in his full talk, available for free here. If you are working on or interested in Docker security, his talk is worth your time.

    Thirsty for more DevOps discussions led by practitioners (not vendors)?  You too can binge watch 99 other talks from the All Day DevOps conference here.

    — Derek E. Weeks

  • 200 Billion Downloads Can’t Be Wrong

    200 Billion Downloads Can’t Be Wrong

    Laurie Voss, COO and co-founder at npm (@seldo), tweeted recently that JavaScript packages downloaded from their repository has topped 4 billion. On an annual basis, that would be more than 200 billion downloads. Wow.

    Just as open source software turns 20 years old this year, these numbers are a testament to the incredible magic that happens when communities of developers openly share innovations.

    Laurie estimated that 12 million developers were responsible for the downloads. That means, on an annual basis, each JavaScript developer will download nearly 17,000 components. Imagine the time saved by not needing to code each of those functions from scratch simply by downloading a package in a millisecond from the internet.

    Software Supply Chains at Work

    What we’re witnessing here is a software supply chain in full effect. Open source projects contribute packaged code to the community, place it in public warehouses, and it’s then consumed by development teams around the globe to create new front-end, back-end or mobile applications for all of us. Every development team on the planet now utilizes a software supply chain that operates at insane speeds with massive throughput.

    In a second tweet, Laurie wrote, “Since we have ~12 million users, that means the average user installed the neatly round number of 1000 packages in 7 days. In reality, most individuals installed very few packages, and a bunch of CI build boxes installed 10s or 100s of thousands of packages each.”

    Essentially, there is an army of robots (automated CI tools) downloading billions of components from the web. While this type of automation is efficient, by itself it does not serve teams well.

    Repositories to the Rescue

    At Sonatype, we saw similar behavior by developers in the early days of Maven. Individual developers would download Java components directly from Maven Central. Maven users sitting right next to one another in the same room and on the same team would download the same versions of the same components needed for their builds, repeatedly. It was for this reason, among others, that our founders invented the Nexus repository manager.

    While repository managers have been used for quite some time in the Java community, Laurie’s post tells us that adoption of the technology still lags in younger, less mature, packaged code ecosystems.

    Companies looking for repository managers can look toward solutions like e-npm, an on-premises technology exclusively for JavaScript packages. For companies with polyglot development teams, universal repository managers provide full-function, (sometimes) free support for npm and 12 other component types, including Docker containers.

    Not All Components Are Created Equal

    I have often said that if you have 100 developers, you have 100 front doors open into your organization. If you have 1,000 developers? Then there are 1,000 front doors.

    If you dissect Laurie’s comment further, you will also realize that any developer can bring any package into your organization at any time. While this does make them more efficient, it also points to security and governance concerns. Every component was developed by someone else, donated out to the internet and consumed in the millions. But you have no true idea of the source or origin of many of the components.

    Research I have done in previous years at Sonatype demonstrated that 5.5 percent (1 in 18) of components downloaded by repository managers had known security vulnerabilities. While the percentage is not very large, keep in mind that a repository manager will only download a component once. Once cached, future downloads of that component are unnecessary and the components can be reused infinitely by that team.

    Sonatype analysis of more than 40,000 Nexus repositories reveals that the average repository holds more than 1,600 components. Deeper analysis of the 1,600 components housed in the average repository manager found 192 security vulnerabilities were present among the components (some components having more than one security vulnerability).

    Within software supply chains, repository managers and private container registries represent procurement gates into the development organization. The gates can be left wide open where component flows are not governed or they can represent opportunities for quality and security checkpoints that ensure defects are not passed downstream.

    What’s in Your Repository Manager is in Production

    Using data from more than 133,000 websites, researchers from Northeastern University showed that “37% include at least one JavaScript library with a known vulnerability. From a per-library perspective, at least 36.7% of jQuery, 40.1% of Angular, 86.6% of Handlebars, and 87.3% of YUI inclusions use a vulnerable version.

    “Alarmingly, many sites continue to rely on npm packages like YUI and SWFObject that are no longer maintained,” the researchers continued. “In fact, the median website in [NU’s] dataset is using a library version 1,177 days older than the newest release, which explains why so many vulnerable libraries tend to linger on the Web.”

    What is Wrong With 200 Billion Downloads?

    Nothing from an innovation standpoint. It’s awesome and we can all celebrate this achievement with Laurie.

    At the same time, it gives us pause to reflect upon other concerns of our day, including cybersecurity threats, technical debt and wasteful context switching.

    — Derek E. Weeks

  • Bridge the DevSecOps Experience Divide with Cross-Functional Teams

    Bridge the DevSecOps Experience Divide with Cross-Functional Teams

    Last week’s DevOps Connect event at RSA Conference offered up a ton of wisdom and real-world examples of the power of DevSecOps. With its best-ever attendance after several years and impressive participation levels, this year’s event stands as a good harbinger for the growing interest that the security community has in vesting itself in the DevOps phenomenon.

    But there’s still a lot of work to do in helping security professionals shift their mindsets and fully understand what DevSecOps is all about. Questions from the audience offered evidence of some of the trepidation and misconceptions that still exist in the security community.

    For example, after one of the first talks of the day, an audience member asked about a typical point of confusion for those new to DevOps—namely, the misunderstanding that the melding of disciplines and the requirement that DevOps team members flex their skills across traditional IT boundaries also means that everyone in IT must be renaissance men and women with a range of in-depth knowledge about all IT specialties.

    “Not everyone can know .NET, not everyone can know Python, not everyone can know firewalls,” the audience member said. “I’ve been doing this a long time and it takes a lot to become an expert in any one of these categories. And yet I’m hearing, ‘Oh, everyone needs to know it all.’ They can’t, so how do you deal with that?”

    This was a valuable question to revisit here, because the response from one particular speaker offers up an extremely important tenet that everyone in the DevSecOps world needs to keep in mind. The answer came from Paula Thrasher, a longtime DevOps evangelist in one of the hardest spaces to implement cutting edge IT processes: federal IT. As she explained, one of the biggest success criteria for a successful DevSecOps transformation is the ability to build fully engaged cross-functional teams. Individuals working within the DevOps are not meant to know everything. Rather, different specialists need to be paired up so the complete team has that full body of knowledge at its fingertips.

    “It’s the fidelity of your collaboration within the cross-functional team that makes this successful,” explained Thrasher, who is director of digital services for General Dynamics, a large federal IT integrator.

    For example, she pointed to one particular team she has seen in her work that is the epitome of a solid cross-functional team.

    “My teams all have mascots, and so one of our teams is the Tigers. The best quote I’ve heard from a team about this topic came from a new employee who said, ‘If one Tiger knows it, they all know it,’” she said. “This is a team that has a crazy diverse background—there’s developers, there’s ops people, there’s a former networker on there—and it doesn’t require everyone on that team to know everything. They collaborate so well that if there’s a network vulnerability, the network guy knows it and tells everybody.”

    This is the why Thrasher sees cross-functional teams that include security people as a big success criteria for DevSecOps.

    “I usually say the first thing should be if your teams aren’t cross-functional, start with that. You don’t have to change anyone’s boss, you don’t have to change anything else about who you report to, but make sure your teams represent all of the skills you need to deliver,” she said.

    Not only will the teams be able to deliver on all of the necessary skills when they’re working as a unit, there’s also an ancillary benefit: In the process, they’ll be training each other, and each team member will end up gaining a more diverse set of skills—and perhaps become renaissance men and women in the process.

    “They might have been a graduate of a cyberprogram and they’re next to a graduate of a CIS-type program and they’re next to a math major and they’re next to a hardware engineer, and they’re all kind of new because they’re recent graduates, but they’re learning with each other and we’re going to train them with some more senior engineers that we self-select to be good mentors,” she said. “This is how you are giving people the skills to work with this next-generation of automation and technology, both in the security realm and the Ops realm and the Dev realm.”

    — Ericka Chickowski

  • 451 Research Report Highlights Value of DevSecOps for the CI/CD Pipeline

    451 Research Report Highlights Value of DevSecOps for the CI/CD Pipeline

    One of the compelling benefits of DevOps for many organizations is speed. Between breaking down silos, streamlining processes and automating routine tasks, the process of developing and deploying software can be significantly faster. A new report from 451 Research and Synopsys, however, points out the value of incorporating DevSecOps in the equation, especially with continuous integration/continuous delivery (CI/CD), and the pitfalls of prioritizing speed without also considering security.

    For the “DevSecOps Realities and Opportunities” report, 451 Research surveyed 350 enterprise IT decision-makers across the United States and Europe, focusing on organizations that have implemented CI/CD. The goal was to learn more about how organizations are implementing CI/CD and the role security plays in that equation.

    For most organizations, embracing DevOps and adopting CI/CD is about speed, not security, the survey found. Shocker! As per usual, security is typically an afterthought—something that might be nice to do if time and resources permit.

    Survey respondents indicated speed as a leading driver for and expectation from CI/CD. “The most organizations (36 percent) sought a 4x factor of improvement in time to deploy from their CI/CD workflows. A significant number (15 percent) sought a 5x factor of improvement. Another 7 percent sought more than a 5x factor of improvement, and 5 percent were seeking a 10x or greater factor,” according to the report.

    The irony is that organizations seem to prioritize speed over quality and/or security at their own peril. Maximizing for speed in the CI/CD pipeline without consideration for security typically leads to more bugs in the code, more downtime and increased time and effort to maintain and remediate applications.

    451 Research points out that as DevOps implementations mature, the focus will shift to what’s truly important. “We believe that as organizations evolve these processes, the focus will naturally move from ‘how fast can development teams iterate’ to ‘how reliably can we deploy high-quality, appropriately secure code each and every time,’” the researchers wrote. “That critical change in focus—that more mature view of risk management—will realign everyone’s expectations on what ‘4x’ really means.”

    Of those organizations that participated in the survey, only about half actually include some sort of application security testing as a function of the CI/CD workflow. Identifying open source software components with known vulnerabilities—also known as software composition analysis (SCA)—is ranked as the most crucial security component for CI/CD by survey respondents, yet nearly 40 percent of the participants admitted that they don’t do any SCA or insist they simply aren’t using any open source code. That seems highly unlikely, though, given that a recent report from Black Duck Software, “Open Source Security and Risk Analysis,” found that 95 percent of applications contain open source elements.

    “While some DevOps teams are starting to incorporate application security into their CI/CD workflows, driven by factors such as improved software quality, compliance and risk avoidance, there is ample room for improvement,” said Jay Lyman, principal analyst at 451 Research. “In many cases, security testing is not being integrated often or early enough in the process for organizations to fully benefit from reduced risk and rework headaches.”

    With security, it always seems a bit like the Bill Murray movie, “Groundhog’s Day”: No matter how many years security professionals have pushed, and fought, and screamed from the mountaintops that security needs to be woven into the foundation of software and integrated into the development life cycle rather than being tacked on with duct tape and chewing gum after the fact, organizations continue to insist on doing the things the harder—and more expensive—way. Hopefully, reports such as this will open the eyes of some organizations and they will break the cycle and start prioritizing security, recognizing that it is actually the best way to develop reliable code as quickly as possible.

    — Tony Bradley

  • Simplify DevSecOps with a Zero Trust Approach

    Simplify DevSecOps with a Zero Trust Approach

    There are major cyberattacks and data breaches weekly, if not daily. Each incident is unique in some way, but one element common to almost all successful attacks is trust. Whether it’s a disgruntled employee conducting an insider attack, an attacker infiltrating the network using stolen credentials or an exploit that leverages a third-party vendor or supplier, what makes the attack possible and allows attackers to fly under the radar is the fact that the credentials and activity appear to be legitimate. A zero trust security approach could solve that.

    In DevOps environments, where new application architectures such as microservices and containers make things much more dynamic and rapidly changing, security can be especially difficult. Automation, virtualization and new tools combine to increase the potential attack surface exponentially. And, granting and removing access for containers or virtual machines that appear and disappear by the hundreds can be a Herculean task—traditional permissions management and access control solutions just can’t keep up.

    “DevOps creates a challenge for many organizations because they need to maintain agility while also recognizing that security is an increasing concern in broadly distributed networks,” said Bill Mann, chief product officer at Centrify. “Prioritizing functional requirements over security while building applications leaves organizations exposed to significant risk.”

    Centrify, however, is up for the challenge of bringing zero trust security to DevOps environments. The company claims to simplify integration of security into DevOps applications development pipelines without restricting development velocity.

    Centrify starts with the premise that users, applications and endpoints are not trustworthy by default. Everything must be verified at every point of access to ensure that security of the development pipeline is not compromised in any way.

    Its DevOps-focused portfolio includes products that help developer, security and operations teams manage access to complex development environments, enhance application security and provide auditable logs of privileged activity. Centrify provides centralized management of user access rights and privileges to Linux and Docker hosts, including hosts running CoreOS Container Linux. I am especially intrigued by its ability to implement multi-factor authentication (MFA) and temporary privilege elevation to gain access to individual containers independent of the container hosts.

    Centrify also announced that it can now be used to authenticate to HashiCorp Vault, one of the most popular tools for securely strong and accessing secrets. Centrify provides centralized access management for the Vault, as well as protects against malware attacks by eliminating the need for locally stored access credentials.

    On the application security side, Centrify focuses on securing privileged service and system accounts and enabling secure communication between applications, containers and microservices. Centrify leverages Kerberos, SAML or OAuth to enable services authenticate to each other.

    The basic premise of Centrify is that “trust but verify” sounds good in theory, but in reality “never trust, always verify” is a much better strategy for security. Rather than hoping you can find the needle in the haystack and identify the one bad actor, it makes more sense to assume the bad guys already exist both inside and outside your network and simply remove trust from the equation.

    The approach certainly seems to have some merit. It’s sort of like applying a whitelist instead of a blacklist to filter email or applications. Rather than assuming everything is good and trying to find the bad ones, just assume everything is bad and only let through the ones you choose. In this case, however, you don’t even have the whitelist. You’re literally verifying the user and device and applying policy to determine the level of access and privilege each time.

    — Tony Bradley

  • Study Traces Cybersecurity Issues to Lack of App Supervision

    Study Traces Cybersecurity Issues to Lack of App Supervision

    A global survey of 400 application developers conducted by Vanson Bourne on behalf of Veracode, a unit of CA Technologies that provides software development lifecycle tools, shines a light on how big an issue cybersecurity has become because of organizations failing to update components. The survey finds only 52 percent of developers using commercial or open source components in their applications update those components when a new security vulnerability is announced.

    Pete Chestna, director of developer engagement for the Veracode, says the root cause of the many cybersecurity issues is that developers routinely incorporate libraries into their applications. But, after completing that task, there is no bill of materials that enables development teams or cybersecurity professionals to keep track of when those libraries need to be updated and for what reason. Without that bill of materials, it’s easy to miss a critical update addressing a newly discovered cybersecurity vulnerability, Chestna says.

    The survey finds 83 percent of developers are using commercial and/or open source components, with an average of 73 components being used per application. But only 23 percent test for vulnerabilities in components as they are updated, even though there are an average of 71 vulnerabilities per application built using third-party components. Furthermore, the survey finds only 53 percent of organizations keep an inventory of all components in their applications.

    The reasons organizations rely so much on open source and commercial software versus writing their own code span everything from best practices (53 percent) and an ability to work faster (51 percent) to being able to access advanced capabilities (47 percent) and company policy (47 percent). Whatever the reason, it’s apparent that more applications are being assembled rather than being developed completely from the ground up.

    The top factors considered when selecting modules to be included in an application include functionality (62 percent), performance (48 percent) cost (44 percent), known security vulnerabilities (42 percent) and reliability (40 percent).

    Unfortunately, there’s not much in the way of DevSecOps processes spanning the development process. This report shows that development (44 percent) or security (31 percent) teams are most likely to be responsible for the maintenance of third-party commercial and open source components. But the number of organizations that enable developers and cybersecurity teams to work together remains relatively small. A quarter admit (25 percent) admit they don’t even have a formal application security (AppSec) program in place.

    On the plus side, more organizations (41 percent) say they are likely to choose DevOps as their IT methodology, which, longer term, should put them in a better position to embrace DevSecOps.

    When it comes to open source software, Chestna says that IT organizations would do well to remember that free software is much more akin to a free puppy versus say a traditional gift. Puppies require ongoing food and maintenance that comes at a cost to the owner. When IT organizations elect to employ open source software, they are assuming a set of responsibilities that many of them still don’t fully appreciate, notes Chestna.

    Of course, the good news is that it’s lot easier to swap out a module of code than it is to return a puppy.

    — Mike Vizard

  • Akamai Extends Scope of DevSecOps Reach

    Akamai Extends Scope of DevSecOps Reach

    Akamai pressed its case for becoming a strategic DevSecOps platform by adding a range of security capabilities to its network service platform that help isolate applications from cybersecurity threats.

    The company has added support for scripting to automate application security using its Kona Site Defender web application firewall as well as improved management and versioning support for application programming interfaces (APIs). Those capabilities complement an Akamai API Gateway for securing and managing APIs.

    Akamai is also updating Akamai Bot Manager, adding a client SDK for mobile applications to help mitigate distributed denial of service (DDoS) attacks. The company also is adding capacity to its scrubbing centers to further defend against large-scale DDoS attacks.

    Ari Weil, vice president of product marketing for Akamai, said the company is evolving into a platform that securely provides web applications with access to caching software and network infrastructure that dynamically scale up and down as required.

    The goal is to make the Akamai network a seamless extension of any DevOps processes that developers can programmatically invoke on demand regardless of whether their applications reside in a public cloud, on-premises or in a third-party hosting center, said Weil. Because Akamai sits between users and production applications, Akamai now plays a critical role in terms of bother DevOps and DevSecOps, he said.

    In term of accomplishing that goal, Weil conceded Akamai doesn’t have as much visibility in the DevOps community as it would like. The company has integrated its platform into continuous integration/continuous development (CI/CD) platforms such as Jenkins to reduce as many steps as possible for DevOps teams. But developers are not always fully cognizant of the security services that Akamai makes programmatically available, he said.

    Weil noted that as DevSecOps continues to gain ground, Akaimai expects many developers will increasingly appreciate those security services, especially as cyberattacks become both more frequent and lethal. A 2017 security report published by Akamai finds DDoS and web application attacks rose 14 percent and 10 percent, respectively, year over year.

    In effect, Akamai turns web application security into a large-scale zero-trust managed service that is available on thousands of points-of-presence (PoPs) around the world. In time, developers will only have to express their intent concerning the level of security to be applied. The execution of that intent will all be automated, Weil said.

    In an ideal world, all cybersecurity battles would be fought as far away from applications as possible. Rather than focusing solely on the edge of the corporate network, Akamai is encouraging DevOps teams to think in terms of layers of defense that starts where applications are cached at the edge of the network. In theory, platforms such as Akamai provide a lot more visibility into what types of cyberattacks are circulating in the wild hopefully long before they ever get a chance to impact an application. The challenge, however, lies in distinguishing between what security technology needs to be embedded in the application itself versus an on-demand service that’s only a simple API call away.

    — Mike Vizard

  • HashiCorp Extends Secrets Management Reach

    HashiCorp Extends Secrets Management Reach

    Secrets management is core to DevSecOps—how credentials are managed can make all the difference in preventing an application from being compromised in the first place. The challenge is making it as simple as possible for developers to access where most of those credentials are stored in the enterprise.

    HashiCorp this week released an update to the open source Vault secrets management software that adds support for both the Microsoft Azure Active Directory Auth Method and the identity and access management (IAM) engine used in Google Cloud Platform (GCP). Those new capabilities complement existing support for LDAP, Amazon Web Services IAM, Kubernetes, GitHub, Okta or others.

    In addition, version 0.10 of Vault adds support for a graphical user interface (GUI). Previously, the GUI was available only in the enterprise version of Vault that HashiCorp supports. But Andy Manoske, a product manager for HashiCorp, said organizations are making it clear they want developers and cybersecurity professionals to make use of the same core secrets management framework. Because most cybersecurity professionals don’t know how to program it became necessary to add a GUI to the core Vault open source software, Manoske said.

    In general, Manoske says developers and cybersecurity professionals are starting to work more closely together. Microsoft Active Directory is the most widely used platform for storing credentials. As enterprise IT organizations start to move more Windows applications to the cloud, enabling developers to programmatically access the credential data is becoming a bigger requirement, he said.

    Additional capabilities in version 0.10 of Vault include the ability to automate the rotation of root credentials at specified intervals and support for versioning. That latter feature is critical for both compliance and disaster recovery purposes, as well as enforcing temporary changes to secrets keys during the investigation of a potential cybersecurity breach, Manoske said.

    From a DevSecOps perspective, Manoske said the biggest challenge remains the reliance on manual efforts to manage secrets within the applications rather than storing them externally in a secrets management platform. Cybercriminals increasingly are making use of automation tools to scan applications for vulnerabilities that enable them to compromise credentials. Vault provides a means for managing credentials that encrypts credentials that can be applied across thousands of applications at scale. It’s hard to see how organizations can address application security without finding some way to automate secrets management, he said.

    Progress in DevSecOps so far has been slow, but steady. Most organizations won’t be able to address DevSecOps effectively until they master DevOps fundamentals. Once that occurs, organizations need to establish a workflow between developers who want to address every function with application programming interfaces (APIs) and cybersecurity professionals that define corporate policies.

    Embracing DevSecOps is, of course, as much about the processes and culture as it is about new technologies. The real challenge is finding a way for developers and cybersecurity professionals to collaborate without seriously compromising the rate at which applications are being developed.

    — Mike Vizard

  • Early Automation: A Key Requirement for DevSecOps Success

    Early Automation: A Key Requirement for DevSecOps Success

    According to the “2017 DevSecOps Community Survey,” by Sonatype, almost 60 percent of the respondents consider security to be an inhibitor to DevOps agility, while more than 50 percent of developers say they do not have sufficient time to allocate to security.

    Hence arises the need for enhanced security automation in DevOps. Security automation helps in refining and improving application security by reducing the time taken for detecting an attack and responding to any identified issue.

    Tools for Security Automation

    Organizations looking to implement DevSecOps by integrating security into their DevOps pipelines have an increasing number of tools such as Tanium, InSpec, Splunk, Checkmarx, Metasploit, FireEye and Contrast Security for security analysis and testing throughout the software development life cycle (SDLC), right from source-code analysis to post-deployment monitoring.

    Early Automation, A Key Requirement for Success Through DevSecOpsFor security to become an integral part of the DevOps workflow, which includes continuous integration and continuous deployment (CI/CD), automation is essential. As most organizations are pushing tens of new versions of code into production for each application every day, it becomes necessary to embed security controls early in the development life cycle, which is possible only through automation.

    Around 40 percent of the 2,300 IT professionals surveyed have said that they have deviated from the waterfall development model, where automated security tests are run just ahead of production, by running them throughout the development life cycle.

    Using SAST Tools

    Static application security testing (SAST) tools help in scanning code and providing instant feedback to developers on security-related issues who, in turn, can remediate the potential vulnerabilities as part of the standard workflow.

    However, static analysis may not be alone sufficient for detecting all problems in the code.

    Automating DAST

    Automated dynamic application security testing (DAST) searches for vulnerabilities in real time while the application is running and is really a major improvement over static analysis that only looks for potential security issues in the code.

    Inclusion of automated security analysis helps in limiting the introduction of vulnerable code earlier in the development life cycle. The runtime analysis of the issues detected through automation enables developers to prioritize the code problems that need to be fixed.

    Red Teaming and Threat Modeling

    Organizations have begun to employ the concept of red teaming, a military terminology, by having separate teams to simultaneously take up attacking the code and performing security testing respectively. This ensures that any potential flaws are uncovered in the production stage itself and code fixes are pushed as soon as possible.

    Threat modeling is critical for the success of DevSecOps as it leads developers to look at software from an attacker’s perspective. While the threat modeling process cannot be automated, it helps in identifying flaws in the application design and architecture better than other security approaches.

    Are You Ready for Automation?

    Organizations can automate the provisioning and commissioning of DevSecOps environments to achieve a predictable, consistent and secure service delivery.

    While the goal of DevOps Services automation is to help development teams in faster deployment and monitoring of applications, DevSecOps adds security to the automation and contributes to enhancing the quality and efficiency of the software.

    DevSecOps adoption provides organizations with a strong foundation for mitigating risk in a proactive, efficient and streamlined manner.

    — Veritis