devopsy.kinsta.cloud

Tag: devsecops

  • What Is DevSecOps and How to Enable It on Your SDLC?

    What Is DevSecOps and How to Enable It on Your SDLC?

    For the past three to four years, all the companies around the IT world have adopted agile and different application development methodologies that leverage the work for different departments or areas and helps them to develop new products and release new features to improve their processes and infrastructure.

    In this new Agile and DevOps world where everybody on a team is involved in the rapid-changing and evolution of their application, we are promoting accountability for everybody in terms of security—this is when DevSecOps joins the party.

    What is DevSecOps?

    DevSecOps is a new model that provides accountability for the security implementation in the application; from the planning, design, development, QA/testing, to release and when operating on a production environment.

    When implementing DevSecOps on the Software Development Lifecycle (SDLC), an organization will experience the continuous integration and will notice that the costs for compliance are reduced, code is constantly being analyzed, tested, delivered and released properly.

    DevSecOps enables the process of implementing security to everybody and makes them accountable.

    Why Is It important?

    As I stated previously on this blog, on this rapid-changing era, everything is evolving at a very accelerated pace. We continue to discover vulnerabilities and breaches across platforms and operating systems, patches are released constantly but we—as part of the operating team of a company—cannot afford the risk of having a vulnerability on any side of our IT system/application.

    Main Benefits

    • Reduces vulnerabilities present on your code.
    • Reduces vulnerabilities present on your IaC technologies.
    • Reduces the number of ways to exploit your application
    • Reduces downtime.
    • Improves your application stability, availability and security.

    How Can I Enable DevSecOps on My Current DevOps Pipeline or SDLC?

    DevSecOps is a must-have methodology that needs to be integrated into your DevOps process/pipeline to help you improve your security on your SDLC.

    There are five important phases that need to be followed in order to enable DevSecOps on a current DevOps pipeline or in the SDLC. Here are the crucial phases to enable it:

    Phase 1: Secure Local Development. Start by implementing secure working-environments. When you are developing an application, in most cases you will use open source technologies. Docker is a great helper at this phase since it automates the infrastructure and services deployments on local machines. So when you are using this ready-to-go docker environment, make sure that you are using the most recent/updated versions of the Docker Images and scan them for vulnerabilities. Even the images from official providers have vulnerabilities that need to be patched.

    Phase 2: Version Control and Security Analysis. Enable Vulnerability while uploading your source code.  Having multiple hands or people working at a piece of code can lead to vulnerabilities, especially when they are remote. Git systems have been a great improvement for collaboration between team members and code. When a team member uploads a piece of code, I strongly suggest that you enable automated testing for security on your code dependencies and core. Some good alternatives to do it are Snyk or Sonatype’s Nexus.

    Phase 3: Continuous Integration and Build. When creating the development image/package, you’ll need to make sure that your build tool or system has the proper security in place. It uses https:// protocol, it’s properly hardened and secure, it’s available and protected for attack mitigation or even not accessible via the internet. The tools that you can use here are Jenkins, Circle CI, AWS CodeBuild, Google Cloud Functions, Azure DevOps.

    Phase 4: Promotion and Deployment. When deploying to an environment, insert the environment variables through your CI/CD tool and try to manage them as secrets. Proper encryption and management of these are recommended in order to enhance your security protocols.

    Phase 5: Infrastructure Security. When your app is deployed, make sure that you have an IDS (Intrusion Detection System). Tools such as OSSEC or Wazuh will help on this matter to protect all your hosts.

    Once your code gets to the production, it doesn’t mean that it will be 100% secure. New vulnerabilities are disclosed every day but this cycle will help you and your team to test your code against all the repository of known vulnerabilities, at the time of monitor, configure, reconfigure, adapt and deploy solutions to the environment.

    Tools and Processes

    These are the tools you will need to enable in your DevSecOps process:

    • CI/CD Tool.
    • Secrets Manager.
    • Version Control System.
    • Docker Orchestration tools.
    • Security Analysis tools.

    And these are the processes:

    • Automated regression testing.
    • Dynamic testing.
    • Automated Vulnerability Assessment.
    • Automated Integration.
    • Promotion.
    • Automated Deployment.

    What Is the Ideal Workflow for DevSecOps?

    1. A developer creates a new code and integrates it into the VCS.
    2. Members from the QA team retrieves the code to perform the static code analysis to identify security flaws or functional tasks.
    3. A test environment is created automatically using IaC such as Terraform, CloudFormation, Chef or Puppet and the security configurations are added to the system.
    4. The test automation suite is performed to the application with a tool usually Selenium or any other tool that performs backend, UI, integration, security and API tests.
    5. After the test suite is performed and successful the new changes are sent to the production environment.
    6. The new version of the code is now going to be monitored in the production environment using an APM or Cloud-native monitoring tool.

    Following these points you are ensuring that your application is following TDD practices improving the code quality, compliance, increasing the number of releases of code to production and reducing the time to market which is essential for any organization.

    What Are the Challenges When Enabling DevSecOps?

    • Enabling too Many Tools: Enabling too many tools can become a problem on your SDLC, especially when your team is not used to work and relate with DevOps/security tasks. The main recommendation here is to start slow. Start by enabling only the necessary tools to get your team familiar with the process and add more when you feel your team is prepared for it.
    • Getting Used to the Methodology: It will take some time for all the team to get used to the DevSecOps methodology/culture and also to keep following it in order to be compliant with the normative that your business demands. Try to always stay up-to-date and coaching your team for the newest technologies.
    • Chasing Perfection on the Process: Keep in mind that all the DevSecOps process won’t be perfect, but it will get mature over time. Teams always try to chase perfection and this only leads to more problems with even more integrations or dependencies.

    Conclusion

    In the end, I think every organization must make the effort to shift to a DevSecOps methodology or process and come up with a multidisciplinary team with a focus on security. That’s how an organization will transition from doing DevOps to DevSecOps. Allowing all their collaborators to have accountability on the part they are actively developing.

    — Guillermo Vélez

  • Report Pins Cloud Security Woes on Flawed DevOps Processes

    Report Pins Cloud Security Woes on Flawed DevOps Processes

    By now it’s become apparent that the bulk of security incidents involving cloud platforms revolve around some type of configuration issue. An analysis of those cloud configurations published today by the Unit 42 research arm of Palo Alto Networks suggests that the root cause of the issue is most likely the templates many developers and DevOps teams rely on to configure cloud infrastructure. In fact, according to Unit 42’s analysis, more than 199,000 templates have medium-to-high vulnerabilities in use on public clouds.

    Matt Chiodi, chief security officer for public cloud for Palo Alto Networks, said the issue stems from the rate at which organizations now want to be able to deploy applications on public cloud. Templates greatly accelerate the process but very few of those templates have been vetted by a cybersecurity team.

    According to the report, the most commonly used templates are created using YAML files on instances of Kubernetes (39%), Terraform and CloudFormation (24%). The most vulnerabilities were discovered in templates created using CloudFormation (42%), Terraform (22%) and YAML for Kubernetes (9%).

    Chiodi noted most templates are created through a simple three-step DevOps process: design, code and deploy. Unfortunately, in the rush to deploy most DevOps teams forget to scan for vulnerability issues. As a result, Chiodi said cybercriminals have become very adept at siphoning off cloud resources to mine cryptocurrencies at low-enough consumption rates to go unnoticed by many IT organizations.

    Other significant cloud security issues surfaced in the report include the fact that 43% of cloud databases are not encrypted and that 60% of cloud storage systems have logging disabled, which Chiodi noted makes it impossible to know whether those systems have been compromised. In addition, the report finds 76% of cloud workloads expose SSH (port 22), while 69% of organizations expose RDP (port 3389) and 27% are using outdated versions of Transport Layer Security.

    Overall, the goal now needs to be to make it as simple as possible for DevOps teams to do the right cybersecurity thing going forward, said Chioti.

    Unit 42 researchers employed a publicly available GitHub Searching application programming interface (API) to find AWS CloudFormation files, Kubernetes YAML files and HashiCorp Terraform files. Hundreds of thousands of templates were then downloaded and analyzed by the Prisma Cloud infrastructure-as-code (IaC) Scanner to identify the insecure configurations. Each IaC file was also sent to an IaC resource checker to analyze the cloud resources being used in the template. Researchers also used Palo Alto Network’s proprietary AutoFocus and Wildfire tools to identify and investigate cybercrime groups through their usage of custom toolsets (malware samples). Those samples were dynamically and statically analyzed to ensure indicators of compromise.

    The Unit 42 research makes it clear there’s a lot of room for improvement when it comes to employing best DevSecOps processes in the age of the cloud. The challenge, however, may have little to do with the tools available. Rather, it’s the absence of a structured set of processes through which DevOps teams and cybersecurity professionals can collaborate that appears to be inflicting the most damage.

    — Mike Vizard

  • DevSecOps: A Renewed Commitment to Secure Delivery, Part 1

    DevSecOps: A Renewed Commitment to Secure Delivery, Part 1

    Security has never been as high a priority than it is today, as companies fear they’ll be the next headline, the next victim of a data breach. Executives also worry about applications meeting the high standards of compliance–either with global regulations such as GDPR, state-oriented privacy laws or the many specific ones covering finance, health care, energy and other industries.

    It’s a bit of a challenge introducing new tools and processes into a longstanding software development life cycle, even when it’s for the sake of increasing security. That’s why companies need to first carefully review their development and production processes to fully understand how they create and release software before they can effectively integrate security into DevOps.

    A reconstruction, so to speak, of application delivery allows companies to step back and smartly modernize their pipelines so there’s minimal human interaction or machine disconnect in newly secured DevOps processes. Involving IT security as a stakeholder in defining governance in a DevOps release pipeline is also crucial. Only then does the “Sec” fit nicely into DevSecOps. In this two-part series, we’ll look at the three critical components that shape a sound DevSecOps pipeline. They are easy to remember: processes, people and tools.

    Vulnerabilities Call for a Maniacal Focus on Security

    Although microservices, containers and cloud-native architectures enable companies to create and deliver applications more nimbly and faster than ever before, many of these innovative technologies also increase the probability of security flaws and vulnerabilities in products. Exposure to risk is much greater with applications being released at higher frequency and in higher quantity as smaller containerized deployment units, as opposed to development happening on a gated monolithic Java application.

    For example, the provenance of images from public container registries can be compromised and thus a potential exposure point in development. Likewise for the proliferation of open source software that is often used as libraries and dependencies. Perennial tools, such as GitHub, have fostered sharing and open communities, sometimes with grave consequences to those contributors that publish sensitive data to public repositories. How many times have we heard about passwords being pushed to public repos for all the world to see? 

    With all those considerations in play and with so much at risk, companies now have a maniacal focus on securing DevOps. But before they can even start formally considering security, they should first review employee responsibilities, organizational accountability, delivery practices, governance and the other aspects that go into the design, development and delivery of digital products. For enterprises that are modernizing to cloud native platforms and technologies, it might be an opportune time to reexamine and freshen up approaches.

    DevSecOps is indeed about people, processes and tools. Fully understand those three and you can build a secure delivery process that engenders trust and confidence in DevOps. Trust and confidence foster accountability and the notion that digital reputations are everyone’s responsibility.

    Determine the Process for the Release Pipeline

    Here, it’s about cementing a formal governance of processes, all the steps behind an application moving from one point to another. How does code graduate from local development and testing to the production station–and what happens in between? This is a fundamental tenet of the plain ol’ DevOps of yesteryear.

    There are notable considerations in a cloud native pipeline. For instance, the promotion path might be described with Kubernetes namespaces and clusters (not the baremetal servers or VM environments of yesteryear). Another modern DevOps approach is to apply DevOps principles to the application and environment configuration artifacts. Also known as GitOps, it’s applying the use of version control, access management and lifecycle processes to yaml files, helm charts, monitoring scripts and other artifacts that are primarily a concern of operations. Extending DevOps to operations (or GitOps) mitigates risk in environment misconfigurations and configuration drift, an added benefit. Security, in this respect, is addressed through environmental compliance.

    Aim to justify everything that happens in the release pipeline. Examine the value-add of steps and align them with the security risks they are trying to mitigate. Here are some examples:

    • Unit tests must pass in the build phase of the release pipeline to mitigate the risk of non-working code being pushed to the Development environment and entering the promotion path.
    • Vulnerability scanning must occur on all Docker images prior to go live to mitigate the risk of a security flaw or vulnerability being introduced in production.
    • All API interfaces must have a Swagger definition and a set of corresponding Pact/contract tests run in build phase to mitigate the risk of integration defects and corresponding outages.

    Seek Answers, Document Everything and Include Security

    By questioning everything, the answers will reveal what falls under the security lens and what eludes it. Ultimately, you want to document practices and processes so that they’re codified and held with reverence by everyone along the pipeline. IT security should have a seat at the table (alongside development, operations, product owner, QA) and be an equally important voice in examining the release pipeline. A core agile value is to have a product-focused approach to the release pipeline. Involving IT security will bring a healthy measure of risk mitigation into the pipeline, while still considering velocity in delivery.

    But that’s just the process. As we’ll explore in the second part of this series, people and tools also make a difference.

    — Andrea C. Crawford

  • DevSecOps: 10 Best Practices to Embed Security into DevOps

    DevSecOps: 10 Best Practices to Embed Security into DevOps

    For companies that employ the agile approach, DevOps seems like a natural extension. Traditionally, enterprises started with integration, development and test automation early in the product lifecycle. Gradually, the agile delivery team took care of iterative development and monitoring practices that increase code quality.

    Today, organizations work in unison to bridge the gap between development and operations (DevOps). They want to offer a faster market delivery with the least human interaction. 

    But what about security integrations? Is there a way to mitigate vulnerabilities early in the development lifecycle?

    The answer is DevSecOps.

    Exploring the Concept of DevSecOps

    DevSecOps is short for development, security and operations. It brings together people, processes and technology to pursue a shared objective. 

    The objective of DevSecOps is to implement security decisions on the same scale as development and operations and make everyone in the product lifecycle accountable for security. 

    Why Should You Adopt DevSecOps?

    People adopt DevSecOps because they are seeking:

    •  Modern alternative to traditional security engagement.
    • Transparent collaboration and workflows during development.
    • Security that’s built into the product, not applied at the final stage. 
    • Reduced expenses and faster delivery rate. 
    • Faster recovery speed in case a threat is detected.

    Steps to a Typical DevSecOps Workflow

    1. A developer starts by writing code within a version control system.
    2. Any required change is committed to the version control system.
    3. Another developer analyzes the code to identify any security defect that may weaken code quality. 
    4. An environment is created to deploy and apply security configurations to the system.
    5. Next, a test automation suite is executed to evaluate the newly deployed application.
    6. After it passes the automation test, the application is deployed to a production environment.
    7. This new production environment is actively monitored for security threats. 

    While there is no right way to transform organizational culture, below are a few components necessary to sustain a DevSecOps environment: 

    Let Developers Get Security Right: Developers are responsible for security. Therefore, you must keep them on top of cybersecurity best practices through continuous training and learning activities. 

    Promote an Open Culture: Openness in communication within the enterprise environment can drastically improve development and security. One way to keep information transparent is by using metrics and dashboards wherever possible. 

    Get Experts on Board: It is extremely difficult to transition from DevOps to DevSecOps without the supervision of expert security professionals. Hire people who understand security within the development and operations environment and let them train your DevSecOps team for the big transition. 

    Tempted to embed security into DevOps? How do you ensure that the best practices are followed? We have answers.

    The Best Way to Implement the DevSecOps Process

    Gather a single group of professionals (admins, developers, security engineers and testers) that are aware of your product from start to end. They should know your requirements and should be experts in deploying, monitoring and implementing new changes. 

    Once you have your team ready, here’s what you need to do next.

    Plan

    Planning is crucial. Do not just stick to feature descriptions. Instead, go for detailed user stories that include:

    • Functional and nonfunctional requirements (e.g., security and performance).
    • UI and UX designs.
    • Acceptance test criteria.
    • Threat models.

    Develop

    Start by evaluating your existing practices. Choose the best resources to build a development model in coherence with security guidelines. 

    Build

    Automated build tools can do a lot more than compile codes. Use them to conduct test-driven development, enforce quality standards and ensure that the best security practices are implemented through static code analysis. 

    Test

    When it comes to a DevSecOps environment, test automation is not limited to UI-focused Selenium tests. Optimally, your security practice should include the following:

    • Unit testing.
    • Front-end testing.
    • Back-end testing.
    • API testing.
    • Database testing.
    • Passive security testing.

    Secure

    Because development, operations and security go hand in hand, only a few issues are left unattended toward the end of the development process. 

    When vulnerabilities are identified, there is a better chance of determining if they are potential exploitations or false positives. 

    Deploy

    Automated provisioning and deployments can be utilized to accelerate product delivery and add consistency in the development process. Using an infrastructure-as-code tool, one can audit properties across the IT infrastructure and enforce secure configurations in a system. 

    Operate

    Routine maintenance and upgrades should be an indispensable component of your operations team. Leverage infrastructure-as-code tools to patch zero-day vulnerabilities and apply updates to the entire organization’s infrastructure. 

    Monitor

    A continuous monitoring plan should be in action to generate real-time stats of how your system is performing. In case any exploitation is recorded, it can be addressed immediately. 

    Scale

    Traditional data-center operations cannot entirely replace a compromised environment. Today’s ability to scale infrastructure through virtualization and the cloud, while addressing the demands of modern-day IT user base, should go a long way. 

    Adapt

    When it is about sustaining an agile practice, continuous improvement is key. This is also true for DevSecOps practices, as you improve and adapt throughout the software development lifecycle.

    Conclusion

    DevOps isn’t going anywhere, anytime soon. It is the new phase of developing, releasing and updating products in a software lifecycle. 

    That’s why high time security professionals let go of the traditional security stack and embrace security solutions at the speed of DevOps.

    — Deepak Gupta

  • Certificates a Fly in the DevOps Ointment

    Certificates a Fly in the DevOps Ointment

    The way cybersecurity teams have managed certificates is turning out to be a major impedance that could best be addressed by more organizations adopting best DevSecOps practices in 2020.

    A survey of 108 attendees at the recent DevOps Enterprise Summit 2019 conference conducted by Venafi, a provider of tools for assigning identities to machines, finds 75% of respondents said they are concerned that corporate certificate issuance policies slow down development.

    In addition, 39% of respondents believe developers should be able to circumvent corporate certificate issuance policies to meet service level agreements (SLAs) and about half (48%) said they are confident that developers always request certificates through authorized channels.

    Kevin Bocek, vice president of security strategy and threat intelligence at Venafi, said the root cause of the friction between developers and cybersecurity teams can be traced to reliance on ticket-based systems for managing IT. DevOps teams in the age of the software engineer are building and deploying applications faster than ticket-based systems based on manual requests can keep up with, he said.

    Rather than wait on IT Operations teams, DevOps teams are doing an end-run as business leaders push for applications to be deployed faster. In many cases, DevOps teams are attaining certificates directly from a cloud service provider such as Amazon Web Services (AWS), Bocek noted. Unfortunately, that can lead to other issues: More than half of respondents(55%) said their organization experienced a certificate-related outage in the past 12 months. Not all those outages are likely to have resulted from DevOps teams working without internal IT, but it does confirm how deeply flawed the existing process of issuing certifications already is.

    To address that issue, Bocek said organizations will need to shift to an approach for issuing trusted certificates that is based on a standard set of REST application programming interfaces (APIs) and is a natural extension of the DevOps processes baked into a continuous integration/continuous delivery (CI/CD) pipeline.

    Unfortunately, most organizations are not especially aware of best practices for issuing trusted certificates. The Venafi survey found three-quarters of respondents (75%) are unfamiliar with the “Securing Web Transactions 1800-16 Practice Guide,” available in draft form from the National Institute of Standards and Technology (NIST).

    Bocek said the days when cybersecurity teams could employ certificates as a means for governing when applications are deployed are all but over. Cybersecurity teams need to collaborate with DevOps teams to define a set of best DevSecOps processes through which trusted certificates still play a role in helping secure the IT environment without slowing down the application deployment process, he said.

    It may take a while for DevOps teams and cybersecurity professionals to get on the same page in terms of issuing certificates. However, as pressure to deploy applications faster continues to mount, cybersecurity teams will need to adjust their policies and processes. How certificates are issued may be as good a place to start their DevSecOps transition as any.

    — Mike Vizard

  • Secure Your Network: How to Integrate EDR and DevOps

    Secure Your Network: How to Integrate EDR and DevOps

    DevOps and Endpoint Detection and Response (EDR) solutions converge when no human element is required while deploying applications or detecting the threat and executing preventive measures. In this article, I am evaluating how the DevOps process integrates EDR solutions for securing services operations at various endpoints in the network.

    What is DevOps?

    DevOps has an impact on the mindset and technology landscape of software development companies to build cloud compatible services in a highly competitive market environment. Unification of development and operations is streamlined in DevOps that results in more innovation in technology domain driven by software. With DevOps, automation has become a more critical element than software development cycles. Now, updates, fixes and patches to software application services become easy with DevOps.

    DevOps Challenges

    Over time, it is realized that security is overlooked while moving to DevOps culture. Here are some of the challenges the DevOps approach might have:

    Absence of Security Knowledge: It is a known fact that a lack of knowledge of secure coding and ignorance of robust security practices by developers can cause a long development cycle. It can happen due to training to developers for following security methods and guidelines while writing code and committing for the build. It has to be addressed at the development level by companies.

    Open-Source Software Security: Use of open source frameworks has increased over time in a DevOps approach. With open-source projects, DevOps teams get pre-made code snippets to enhance the functionality of applications. But a striking fact is that 41% of cyber-security applications found high-risk open source vulnerabilities. To encounter this challenge, the DevOps team should be literate to track updates to open source frameworks used in DevOps toolchain, apply fixes to vulnerabilities as it becomes available. Also, to integrate open source, only use the trusted repositories.

    Inverse Speed for Security Testing: DevOps introduces automation with agility in developing and releasing software applications. The speed at which developers commit code and build an executable does not allow the testing team to deep dive into code efficiently. In the traditional model, testers used to get a fair amount of time before applications go live. With the new agile approach, the duration for testing becomes much lower. To tackle this, automation in testing needs to be in line with development.

    What is EDR?

    EDR solutions offer a new approach to continuously monitor network endpoint devices for malicious activity and prevention of the attack and trigger a further course of action based on the pattern of attack. These solutions analyze endpoint data actively to provide detection and prevention in real-time. EDR solutions analyze the behavior of endpoints users and/or devices for suspicious activity and send alerts to the system.

    EDR replaces the use of digital signatures to detect threats and provide behavior-based solutions for proactive security threat intelligence. All the processes of EDR solutions are based on activities, events and interactions on endpoints or with endpoints. 

    In the realm of CyberSecurity, EDR security offered to enterprises has the topmost priority due to its nature of being proactive and automated. 

    How Does EDR Solve DevOps Challenges?

    DevSecOps is all about introducing and utilizing tools/solutions to secure continuous integration, development and delivery of applications. These applications made for services run at either server-side or endpoint devices. EDR solutions work actively in systems where endpoints have participated. EDR solutions can be integrated within the DevOps cycle so malicious activity can be tracked and hunted down by developers. This can be the quickest and automated way to tackle security threats.

    The public cloud provides an environment for developers for the development, testing and execution of applications. The DevOps approach is mostly consumed by public cloud vendors with their set of supporting tools. But the cloud has its security concerns—such as any misconfiguration or code glitch in the application resulting in a huge attack. Also, cloud resources are mostly accessed by various types of devices which may or may not be secure. Some developers use their own devices for the development and monitoring of the application. EDR solutions can help in both cases by applying itself at endpoints as well as at public cloud infrastructure end.

    Conclusion

    EDR solutions are based on machine learning technologies that generate actions based on analytics information provided by sources/endpoints. EDR tools integration with the DevOps toolchain takes automation in process execution at much further level to track security breaches in run time and hunt down vulnerabilities within code before the application goes live. Additionally, it has seen that endpoint devices are more significantly emerged in generating security incidences. It has become imperative for DevOps teams to look after endpoint protection.

    — Sagar Nangare

  • CNCF Graduates TUF Project to Secure Software Updates

    CNCF Graduates TUF Project to Secure Software Updates

    The Cloud Native Computing Foundation (CNCF) announced today that an open source specification for securing software update systems has graduated to becoming a top-level project.

    The Update Framework (TUF) is made up of a set of libraries, file formats and utilities that can authenticate files and images before they are downloaded from a software repository. Justin Cappos, associate professor of computer science and engineering at NYU Tandon School of Engineering who led the development of TUF, said the framework enables IT organizations to better secure their software supply chains.

    In addition, TUF isolates artifacts in a repository in a modular fashion that not only limits the amount of damage that can be inflicted by a breach of the repository, but Cappos said it also makes it easier for IT organizations to roll that repository back to its last known good state.

    For a CNCF project to graduate it needs to demonstrate thriving adoption, an open governance process and a strong commitment to community, sustainability and inclusivity. TUF was developed at the University of Washington in 2009 by Cappos and Justin Samuel. TUF has been based at New York University Tandon School of Engineering, which makes a reference implementation available to any interested party, since 2011. It became a CNCF project in 2017 and is now the first security-oriented project to graduate among the eight other CNCF projects that have graduated.

    TUF is already employed within Notary, a separate CNCF project that provides a mechanism to both certify the validity of the sources of Docker images and encrypt the content of those images. TUF is also employed within Uptane, which is employed to deliver software updates to automobiles. Other organizations using TUF in production environments include Amazon, VMware, Google, IBM, Red Hat, Datadog and DigitalOcean.

    Cappos said he would like to see TUF adopted more broadly to secure software supply chains in medical systems as well as critical infrastructure systems such as the power grid. As cyberattacks targeting these systems increase, Cappos said it’s apparent there is a need for a more resilient approach to securing software running on these types of platforms.

    Longer-term, as organizations embrace best DevSecOps processes, it’s now only a matter of time before organizations focus more of their time and energy on securing the software supply chain. However, Cappos said right now there is too much focus on trying to discover application dependencies and scanning images. While those are important tactical tools, Cappos said there needs to be more focus on strategic approaches to securing software supply chains.

    It’s not clear to what degree DevSecOps will ultimately push organizations to embrace a more holistic approach to building and managing software supply chains or whether larger concerns about the security of software will push more organizations to embrace DevSecOps. Regardless of whether the impetus for building and deploying more secure software comes from the top down or the bottom up within an organization, the important thing is that in terms of tools and processes rapid advances are finally being made.

    — Mike Vizard

  • Why Is Security Missing in Many DevOps Implementations?

    Why Is Security Missing in Many DevOps Implementations?

    The exceptional and ground-breaking, technology-driven opportunities in today’s digitized age come with significant competitive pressures to transform promptly. Specific demands increase due to continuous repeating in response to customer preferences becomes the more deep-seated expectation. To overcome this issue, organizations are shifting toward DevOps as a medium to deliver innovations quickly.

    DevOps also promotes innovation and agile software development but, for optimal results, proper security implementation is required. When business security teams are more cohesive in the development culture it is easier to secure new developments from the start. 

    DevOps is all related to automation and speed. At times this can make the apps in development get exposed to malicious attacks, which results in various scams. However, the end customer is seriously concerned about the security feature. The tools you’re going to choose might be vulnerable to different security issues. Hence, it is essential to select those tools that comply with security concerns, such as the General Data Protection Regulation (GDPR).

    DevOps culture is driven by moving fast yet in small pieces. It offers organizations with a wide range of benefits, which includes cooperation among stakeholders, development processes, improvements in code quality, as well as enhanced business velocity. 

    DevOps is responsible for solving different challenges in the software development process, but at the same time, it also familiarizes new challenges. It is found that less than 46% of IT experts are neglecting security in DevOps design and planning. Such environments end up with an inactive and uncoordinated approach to incident management and mitigation.

    There are several reasons for security being missed during DevOps implementation. Some of them are discussed below.

    Cultural Resistance to Security

    It is a standard view in many organizations that introducing security will lead to a slower development process. However, the overall effort and time cost of catching some security flaws early in the design or development process is much lower than to fix the problematic code and weaknesses later during the development cycle. 

    More Focus on Speed Than Security Teams

    DevOps teams are often associated with InfoSec teams. DevOps induces and modifies code batches over a short period, which might far outpace the speed at which the security teams can keep up with code review. If security—code analysis, configuration checks and vulnerability scanning—is not adequately automated, the DevOps output will eventually be slowed down or result in a lack of security hygiene. 

    Practically, this fallout consists of insecure codes, inadvertent vulnerabilities, hard-coded passwords, misconfigurations and other weakness in-app security that can contribute to operational dysfunction or get exploited by attackers.

    DevOps and Cloud Environment

    A typical DevOps environment is dependent upon cloud deployments, which often shares many cloud security considerations. DevOps teams influence the latest, open-source and even immature tools to manage various security groups and server instances. In this digital age that function at large scale, a slight misconfiguration error or security malpractice can be widely propagated, resulting in extensive operational dysfunction or other exploitable compliance and security issues.

    Poorly Managed Access Controls

    Most of the aspects of DevOps are interconnected, changing rapidly and utilizing secrets. DevOps secrets might include private account credentials, APIs token, SSH Keys, etc. that might be used by both humans and non-humans, for example, apps, containers, cloud instances and microservices. Ineffective secrets management is a common flaw in DevOps environments. It provides a provoking possibility for attackers to interfere with the security and other controls, disrupts functions, steals information and exploit an organization’s IT infrastructure. 

    Moreover, to further advance the workflows, DevOps teams might also allow unrestricted access to some private accounts by multiple individuals, who might share their credentials. This is a practice that eliminates the chances of a clear audit trail. Several methods, configuration management, as well as other DevOps tools, might be granted immense privileges. With access to private accounts, an attacker or even a piece of malware can get full control of the data and systems.

    Security should be a top priority of an organization while implementing DevOps, but due to the practices mentioned above it is often neglected.

    How to Ensure Security in DevOps?

    Sticking to security helps the team to come up with quality code. This practice makes developers write error-free codes. When this culture turns into a norm, it fosters the DevOps efforts as a whole. Below are some of the ways to ensure security in DevOps:

    • Set a priority list and put things according to it. Shift the security focus to the left in the development lifecycle.
    • Ensure that developers are well aware of the security consequences and principles and follow the same path as of yours.
    • Educate and train your developers to use particular tools to build secure systems, as well as also keep your DevOps system safe.
    • Set up an alerting and monitoring system to avoid any damage in the end. 
    • Do have proper metrics and submit reports daily to ensure that everything is under control.
    • Various compliance tools and the best business security systems should be introduced into the toolchains. If the codes fail to pass security tests, the build breaks and does not gets deployed so, sent it back to the developer for further refining.
    • Adopt different configuration managements. It means do scans to identify and remediate possible errors. Stabilize all configurations by using the industry’s best practices. Also, allow continuous configuration and hardening baseline scanning across various servers and codes which are built for cloud assets.
    • Do prioritize the deployment of automated tools to detect possible threats, problematic or vulnerable codes and other issues with process and infrastructure. More strictly, you will match the speed of security to the DevOps process; the less you’re going to come across culture resistance, which is embedded in the security practices.
    • Shift toward the rising trend of DevSecOps. It is a practice of injecting security in the lifecycle of app development. It reduces vulnerabilities and brings security much closer to business goals.

    Final Thoughts

    Security is a crucial element in DevOps implementation because it influences the bottom line of any organization. At times, security is missed out, but if this continues it will eventually lead to exploitation by hackers and loss in customer trust. Remember, everything can be recovered, but once a customer’s trust is lost, it can never be gained again. Thus, it is imperative to ensure security while implementing DevOps and achieve success by leaps and bounds.

    — Farwa Sajjad

  • Practical Approaches to Long-Term Cloud-Native Security

    Practical Approaches to Long-Term Cloud-Native Security

    There is no shortage of advice out there about how to secure modern, cloud-native workloads. By now, most developers and IT engineers who work with cloud-native deployments have heard all of the mantras about DevSecOps, shift-left security, multi-layer defenses and dynamic baselining (to name just some of the key concepts that are driving IT security conversations these days).

    One thing is to talk about security best practices and another is to design a cloud strategy that makes it not only possible but also easy to implement them. Even more challenging is planning a strategy that facilitates security best practices over the long term.

    Keep reading for tips on meeting these challenges and devising a long-term security strategy.

    Security Is a Long Game

    It’s easy to think of security as something you have to do in real time. After all, threats and attacks usually happen suddenly, and reacting to them quickly is key to preventing serious damage.

    If your security strategy centers on finding and remediating threats as they appear, you end up stuck in what is essentially a break/fix mode. You’re constantly reacting, rather than being proactive.

    A much more effective security strategy is one that minimizes the threats you face in the first place. That type of strategy requires long-term planning.

    Sure, you will always need to be prepared to detect some threats that you didn’t anticipate, and react quickly in the event a breach occurs. No security plan is perfect, and the unexpected will sometimes still happen. But by focusing as much as possible on long-term security solutions that stop most threats from materializing, you end up with a much safer and more reliable security posture.

    Building a Long-Term Security Strategy

    What does it actually take to implement a security strategy that protects you over the long term? It all boils down to four elements: data, infrastructure, processes and culture.

    Data

    For many organizations, data stored in the cloud is the workload that poses the greatest risk. It’s the reason why there is a seemingly never-ending stream of headlines about major security breaches that involve the theft of sensitive data stored in the cloud.

    Therefore, mitigating threats to data in the cloud is a critical requirement for long-term security. Some best practices in this regard include:

    • Assess your data: Data security starts with knowing what is in your data, and how sensitive the data is. Data cataloging can help with this process, but so can tools such as Amazon Macie, which helps identify personally identifiable information with cloud-based data.
    • Access control: Access control frameworks are another crucial line of defense against cloud-based data breaches. Just remember that simply enabling IAM is not enough; you must also audit IAM policies to avoid misconfigurations that could lead to a breach (which was the lesson learned by Capital One, among others).

    Infrastructure

    These days, we tend to treat infrastructure–meaning the cloud-based and/or on-premise data centers that host workloads–as a relatively generic and interchangeable part of the solution stack. But while it is true that, generally speaking, no one cloud or data center is inherently more secure than another, the way you design your infrastructure plays a key role in your ability to secure modern workloads over the long term.

    Best practices on the infrastructure front, for long-term security include:

    • Immutable infrastructure: Embrace infrastructure platforms, such as ECS or EKS, that make it easy to deploy and update applications in an immutable way. Immutable building-blocks may not work for all use cases, but where possible, they reduce the number of variables and handoffs you have to contend with in order to deploy or update an application (and the more variables and handoffs, the greater the chance of an oversight that will create a security vulnerability).
    • Access control: While IAM frameworks can help prevent some types of unauthorized access, you can also increase the security of your infrastructure using Access Control Lists. A best practice is to adopt a whitelisting approach that blocks all traffic by default, and allows only explicitly trusted hosts.
    • Avoiding bloat: Cloud-native infrastructure makes it easy to spin up virtual machines, databases or other infrastructure components that you don’t truly need, and keep them running. Doing so increases your attack surface. For that reason, identifying and shutting down unused infrastructure is critical for ensuring long-term security. It also helps cut cloud costs, but that is another topic.
    • Parity: In order for developers, ITOps and security teams to be able to communicate and coordinate effectively, they should all be working with the same types of infrastructure environments. Collaboration becomes much more difficult if, for example, you use an on-premise data center for development, then deploy production workloads to the cloud. Avoid this by striving to create parity across your infrastructure whenever possible.

    Processes

    Processes are the second key ingredient in creating a long-term security plan for cloud-native workloads. Obviously, the processes you use will reflect, in part, your particular workloads and tools. But no matter your situation, your processes should be designed with the following security goals in mind:

    • Consistency: Your IT organization may consist of different teams, each with different responsibilities and agendas. Nonetheless, to the extent possible, all teams should follow the same procedures when developing, testing, staging and deploying applications. Doing so reduces the chances of variables or oversights that can undermine security. You can help achieve this consistency by creating and enforcing IT governance procedures across the organization.
    • Shift-left: Processes are the part of your IT operation where shift-left security can have the greatest effect. Shift-left security means making security a priority from the start of the application delivery pipeline. Importantly, however (and this is a point that some organizations overlook), doing shift-left security correctly also means bolstering security operations at later stages of the pipeline, too. Don’t just shift security left and call it a day; aim to make security a primary consideration at all stages of your delivery chain.

    Culture

    Culture is something that can be difficult to formalize; indeed, if you try to stuff cultural values down your employees’ throats, you risk compromising the whole point of having an organic culture in place. Instead, you want to encourage your team members to naturally embrace values that promote a culture of security. Strategies that can help achieve that include:

    • Bug bounties: Incentivize your team to look for and address security issues by hosting bug bounties for your organization’s workloads. For this purpose, “bug” should be defined broadly to include not just security bugs within code, but any kind of configuration issue in your infrastructure, tools or applications that could lead to security vulnerabilities. That way, your bug bounties can include not just developers, but all members of the IT organization.
    • Encourage shared ownership: A culture in which each engineer owns a specific application, infrastructure or process is one that limits transparency and opportunities to address security risks. Strive instead to promote shared ownership of IT assets so each team member knows his or her work may be reviewed by others, which helps to encourage best practices and reduce security issues. In essence, these are part of the values that DevOps and DevSecOps prioritize.

    Conclusion

    By designing infrastructure, processes and cultural practices that promote security, you put your organization in a position to optimize security over the long term. Planning ahead for security is the only way to escape the break/fix cycle of responding to vulnerabilities as they are discovered, which leaves you always treading water and never pushing the needle. You won’t be able to prevent all security issues, but you can greatly reduce the number that crop up by baking security into your infrastructure, processes and culture.

    This sponsored article was written on behalf of Eplexity.

    — Chris Tozzi

  • DevSecOps Requires Teamwork for Success

    DevSecOps Requires Teamwork for Success

    While the manifestos surrounding the current development pipelines may differ, there is one concept that remains constant: teamwork. All the various frameworks populating the development landscape bring together teams of people to build and deliver applications. This is especially true of DevOps, which focuses on a technical culture with defined roles on a quest for responsiveness. 

    Yet, many organizations seem to be failing miserably when it comes to bringing cybersecurity into IT operations, especially where DevOps is concerned. New research from Tanium, a purveyor of endpoint management and security platform solutions, illustrates that all is not well where cyber and IT operations intersect.

    Tanium commissioned Forrester Consulting to survey more than 400 IT leaders at large enterprises to uncover the challenges, consequences and gaps they face when managing and securing their endpoints. That research revealed that two-thirds (67%) of businesses say that driving collaboration between security and IT ops teams is a major challenge.

    That lack of collaboration has a cascading effect, impacting the overall security hygiene of the enterprise and exposing systems to even common threats. Simply put, teamwork requires much more than just building camaraderie between security, operations and development folks; success requires that various team members come together to support the culture of DevOps. 

    Strained relations between those players can lead to security failures, an assumption evidenced by Tanium’s research. The survey results indicated that security and IT ops teams with strained relationships more often struggle with basic IT hygiene, taking nearly two weeks longer to patch IT vulnerabilities than teams with healthy relationships.

    It is those types of issues that can weaken the confidence of  IT decision-makers to make the correct decisions. The report claims that they have a misplaced sense of confidence, with 80% certain they can act on the results of vulnerability scans but only 49% feel confident they have full visibility into all the hardware/software assets on their environment. 

    According to Tanium, that misplaced confidence is attributable to the increased investment in IT security and operational tools. However, just increasing security budgets does not always deliver on improved capabilities. As the survey results indicate, throwing money at the cybersecurity problem often creates a false sense of security regarding how well businesses can protect their IT environment from threats and disruption.

    Many of those threats seem to fall through the cracks, a problem often blamed on the lack of end-to-end visibility of endpoints and their health. Solving that particular issue requires that IT security professionals interact more effectively with their IT operations and development counterparts (again, teamwork). Further exacerbating the problem is that many applications and services still operate in silos, which inhibits the visibility and control needed to properly protect the environment.  

    “According to our research, most teams are confident in their ability to take timely action on the results of their vulnerability scans. However, further investigation shows teams are admittedly suffering from visibility gaps of all hardware and software assets in their environment, which undermine these efforts to take action. With around 50% of IT leaders showing confidence in asset and vulnerability visibility, you’re essentially leaving your security to a coin flip,” said Chris Hallenbeck, Americas Chief Information Security Officer at Tanium. 

    Ultimately, Tanium recommends adopting a unified endpoint security solution to address the gaps in protection, while also encouraging security and IT ops teams to work more closely together. However, it is likely it will take more than just that to fully integrate security into the DevOps pipeline. Cybersecurity pros will need to get involved in the development pipeline to ensure that security becomes a foundational element of the application development and delivery process. 

    — Frank Ohlhorst