staging-devopsy.kinsta.cloud

Tag: devsecops

  • 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

  • Raytheon Leans on Red Hat to Advance DevSecOps

    Raytheon Leans on Red Hat to Advance DevSecOps

    Raytheon Company is partnering with Red Hat to drive the adoption of DevSecOps workflows and processes it developed around the OpenShift application development and deployment platform.

    Jon Check, senior director for cyber protection solutions for Raytheon Intelligence, Information and Services, said Raytheon has developed a set of DevSecOps practices for organizations building applications deployed in highly secure environments, involving government contracts.

    Raytheon and these customers have been challenged by a chronic shortage of IT professionals with the appropriate level of clearance to work on these classified projects. To overcome that issue, Check said Raytheon developed what it describes as a “code low, deploy high” approach to DevSecOps. Developers who lack security clearances can still build applications; however, those applications can only be deployed by IT professionals having the appropriate security clearance.

    In addition, Check said Raytheon has developed integrations between its DevSecOps framework and various IT tools based on the ITIL framework, which so many IT operations teams depend on to foster collaboration across the application development and deployment process. For example, he said, whenever code gets checked into a repository, an alert can be sent to an IT service management application from ServiceNow.

    That approach enables organizations to build applications quickly without compromising the integrity of the deployment platform, Check noted. Now Raytheon is working with Red Hat to drive adoption of its approach to DevOps to organizations beyond the core vertical industry and government sectors it serves.

    Check said Raytheon chose to work with Red Hat because organizations are now building applications employing microservices based on containers that they want to be able to deploy on any cloud computing environment. Those environments include edge computing platforms to process data in near real-time closer to the point where data is collected.

    In addition, Check noted Red Hat OpenShift is built on Red Hat Enterprise Linux (RHEL), the first operating system to achieve Common Criteria certification with Linux Container Framework Support. Red Hat also assumes responsibility for curating the underlying open source operating system and application deployment platform.

    In general, Check noted that while there’s a lot of interest in deploying code faster these days, the deployment of insecure applications is counterproductive. Organizations too often find themselves rolling back application deployments to deal with one cybersecurity issue or another. By separating application development and deployment, Raytheon is making the case for a DevSecOps approach that enables more secure application code to be deployed faster, he said.

    Each organization will have to determine what rate of application deployment is fast enough for them. The more sensitive the application is, the more an organization is likely to want to be more deliberate when it comes time to deploy and update an application. However, the need to be deliberate doesn’t necessarily mean organizations should continue to rely on legacy approaches to application development and deployment based on waterfall methodologies.

    — Mike Vizard

  • DevOps: Get the Basics Right to Avoid Costly Mistakes

    DevOps: Get the Basics Right to Avoid Costly Mistakes

    It is a truth of both agile and DevOps that speed is of the essence. This is a relative statement—some apps/portfolios/orgs envision speed completely differently than others—but if you are releasing more frequently than you were in the past, thanks to DevOps, that’s kind of the point.

    Yet, we see a whole selection of things that fall by the wayside or are underserved. Security and testing are the easy/obvious ones. Considering the frequency with which we see “Unsecured Amazon storage bucket” (one announcement of this type spurred this blog), should we not see this folded into standard procedure or tools? Well, it is folded into standard tools for checking your cloud environment—I’ve used a couple of them and seen this warning come up. So shouldn’t organizations be using these tools more?

    One thing about speed: It tends to cut corners. And cut corners lead to lapses. You can be a blameless environment that doesn’t punish people for mistakes, but for an organization, a mistake such as exposing hundreds of thousands of users will be punished from the outside, from regulatory agencies and the market in general. They’re not mistakes we should be making, and yet it still happens.

    Another one is rollback versus roll forward. Most DevOps shops focus on the ability to fix an issue and plow forward. This works really well, 90+% of the time, and fails spectacularly sometimes. While it is an added step with some slowing of process, being able to roll back changes is important. And more than, “Well, theoretically, Git will allow us to go back to the last marked release …” because there is far more to an application architecture than just the source stored in a repository.

    In short, no matter how fast things are going, have a plan for when things go wrong. Because they inevitably will. And take the little bit of extra time for preventatives such as warning someone other than the creator about buckets with no security.

    “But there isn’t time …” is the common refrain to blogs such as this one. I get it. The increase in delivery only creates an increased appetite for delivery. But is there time to respond to disaster, should the worst happen? And I’d argue that it must be IT that plans for disasters. When someone gets fired because there was a security breach or a total systems failure, it is rarely an app owner. That puts the responsibility to make certain one doesn’t happen squarely on IT.

    We’re delivering faster, offering increased functionality to users, moving forward on every front. You all are out there rocking it daily. Don’t risk all of that being ignored because you failed to take care of basic issues. Check out the tools to help out; feature flags and cloud security scanners both spring to mind with regard to my examples above. The tools are out there, you just have to work them into your process.

    — Don Macvittie

  • DevSecOps Adoption and the Web Security Myth

    DevSecOps Adoption and the Web Security Myth

    As DevOps practices have become widespread in the tech community, many people have begun proclaiming the virtues of DevSecOps. As the name implies, DevSecOps is the addition of security into DevOps. Just as DevOps promises better-quality production in less time, DevSecOps promises better security with less time required to achieve and maintain it.

    DevSecOps has many benefits. However, many executives are under the impression they can’t embrace DevSecOps across their entire organization.

    This idea is false. Most organizations that have already adopted DevOps can, and should, take the next logical step and adopt DevSecOps as well.

    ‘It Sounds Great, But We Can’t Use It Here’

    Adopting DevOps requires far-reaching changes throughout an organization. Going to DevSecOps can be similarly disruptive. However, internal disruption is not usually the (perceived) problem with DevSecOps.

    Instead, the problem is usually the network border. Many executives believe that their current web security solutions are incompatible with DevSecOps.

    In many cases, this is actually true. Older approaches to web security are indeed hindrances to DevSecOps practices.

    Therefore, the problem isn’t actually with DevSecOps. The problem comes from the security solutions currently in use.

    Legacy Security Solutions and DevSecOps

    Many organizations are still using appliances (whether physical or virtual) as their primary protection against external threats. A decade ago, appliances were good enough. Today, they’re a competitive disadvantage.

    There are several ways in which appliances are incompatible with DevSecOps:

    • Programmatic control of an appliance is often difficult if it’s even supported at all.
    • Configuring an appliance can be challenging. It often requires a high level of security expertise.
    • Rolling out settings and configuration changes across a bank of appliances can be time-consuming and potentially error-prone.
    • The cost and specialized nature of most appliances make them inconsistent with the DevOps mantra of “cattle, not pets.”
    • Physical appliances do not scale.
    • External-facing applications will be limited in their scaling as well.
    • Appliances are not designed for ephemeral workflows.
    • Appliances are not designed to support infrastructure as code (IaC).

    Security appliances represent a decades-old approach to security, so it’s not surprising they don’t support modern practices. What is surprising is that even many allegedly “cloud-native” solutions aren’t built for DevSecOps, either.

    For example, some require multiple instances to be launched into your environments. Some require additional layers of management just to maintain consistent configuration among them. Many do not provide good support for evolving architectures and expanding deployments. In general, these security products tend to require significant intervention and management, while lacking automated control capability. This all severely limits the use of DevSecOps.

    These appliances and incorrectly labeled “cloud-native” solutions are why many executives believe DevSecOps isn’t an option for their organizations. To be clear, these executives are correct—for as long as they continue to use previous-generation approaches to web security.

    Not Just a DevSecOps Issue

    Older approaches to web security have other problems that go beyond a hindrance to DevSecOps usage.

    For example, appliances are marketed as complete web security solutions, but they cannot actually fulfill this role. Among other things, an appliance cannot defend against a volumetric DDoS. The attack can overwhelm the upstream ISP before the appliance even has a chance to scrub the traffic. This can result in the ISP blackholing all incoming traffic, which makes the targeted site and web applications unavailable to users and customers—which is the exact situation the appliance was supposed to prevent.

    Solving the Problem

    Organizations which are still using older security technologies should re-evaluate this decision. Modern solutions such as cloud web security platforms can provide better protection, along with numerous other benefits. These include full management by the provider, real-time reporting and traffic control, adaptive threat identification based on machine learning and much more.

    When organizations continue to use legacy security solutions, they not only prevent themselves from enjoying the benefits of DevSecOps, they are also missing out on many other benefits as well.

    — Maksim Blishchik