Category: DevSecOps

  • Best of 2019: The Time Has Come for an Engineering Approach to DevOps

    Best of 2019: The Time Has Come for an Engineering Approach to DevOps

    As we close out 2019, we at devopsy.kinsta.cloud wanted to highlight the five most popular articles of the year. Following is the third in our weeklong series of the Best of 2019.

    Do you want to know how to do DevOps? Are you doing DevOps but not satisfied with the results you are getting? DevOps is complex. It does not come with a prescription, installation guide, user’s manual or maintenance manual. It doesn’t even have a standard definition. How can anyone expect to get good results with DevOps without clear and definitive guidance? There are plenty of books that describe different aspects of DevOps and customer user stories, but up until now there has not been a book that frames DevOps as an engineering problem with a step-by-step engineering solution and a clear list of recommended engineering practices to guide implementers.

    My book, Engineering DevOps: From Chaos to Continuous Improvement … and Beyond, provides a step-by-step engineering prescription that can be followed by leaders and practitioners to understand, assess, define, implement, operationalize and evolve DevOps for their organization. It provides a unique collection of engineering practices and solutions for DevOps. By confining the scope of the content of the book to the level of engineering practices, the content is applicable to the widest possible range of implementations.

    This book was born out of my desire to help others to do DevOps, combined with a burning personal frustration. The frustration comes from hearing leaders and practitioners say, “We think we are doing DevOps, but we are not getting the business results we had expected.”

    There are many documented references, courses and other sources of information that explain a multitude of different aspects of DevOps, but there is not a comprehensive step-by-step prescriptive guide that details how to engineer a DevOps solution for any organization given any starting point.

    Engineering DevOps takes a strategic approach, applies engineering implementation discipline and focuses operational expertise to define and accomplish specific goals for each leg of your DevOps journey. This book guides the reader through a journey from defining an engineering strategy for DevOps to implementing The Three Ways of DevOps maturity using engineering practices: The First Way (called “Continuous Flow”) to The Second Way (called “Continuous Feedback”) and finally The Third Way (called “Continuous Improvement”). This book is deliberately intended to be a guide that will continue to be relevant over time as your specific DevOps, and DevOps more generally, evolves.

    Structure of this book

    This book is organized as an engineering reference guide presented in five parts as follows:

    Part I: What Is Engineering DevOps and Why Is It Important? is organized into three chapters. Chapter one, “What is Engineering DevOps?,” explains engineering concepts and terms used in this book that have proven to work with many clients I have encountered during my consulting experiences. My depiction of a DevOps Engineering Blueprint is presented for as a useful, practical “big-picture” reference for discussing engineering the major parts of DevOps. Chapter two, “Nine Pillars of DevOps,” describes a classification of DevOps practices that I have found to be useful characterization of DevOps engineering practices readily applied when engineering DevOps implementations. Chapter three, “Why Is Engineering DevOps Important?,” explains the benefits of taking an engineering approach to engineering DevOps.

    Part II: Engineering People, Processes and Technologies for DevOps provides a comprehensive explanation of recommended engineering practices for the higher levels of the DevOps Engineering Blueprint. DevOps transformations are not normally understood or applied using strict engineering principles. Engineering practices are presented in nine chapters. “How Should DevOps Be Engineered?” includes a discussion of DevOps Engineering Maturity Levels for each of the Three Dimensions (People, Process, and Technology), Twenty-Seven DevOps Engineering Critical Success Factors and Lean DevOps Value-Stream Pipeline Engineering.

    I describe recommended engineering practices for the top layers of the DevOps Engineering Blueprint in the next chapters, which include “Value-Stream Management (VSM),” “Application Release Automation (ARA),” “Version Management,” “Continuous Security (a.k.a. DevSecOps),” “Service Catalog,” “Governance,” “Site Reliability Engineering (SRE),” “Disaster Mitigation” and “Recovery.”

    Part III: Engineering Applications, Pipelines, and Infrastructures Engineered for DevOps provides a comprehensive explanation of recommended engineering practices for the lower levels of the DevOps Engineering Blueprint, presented in six chapters as follows: “DevOps Applications Engineering,” “CI/CD Pipelines Engineering,” “Elastic Infrastructure Engineering,” “Continuous Test Engineering,” “Continuous Monitoring Engineering” and “Continuous Delivery and Deployment Engineering.”

    Part IV: DevOps Seven-Step Transformation Engineering Blueprint provides a description and tools for my approach to realize and evolve DevOps. The seven steps are Visioning, Alignment, Assessment, Solution Engineering, Realization, Operationalize and Expansion. By using these tools, DevOps leaders and practitioners can create, implement, operate and expand their DevOps across the organization. The chapter goes further to explain how to evolve DevOps from a successful First Way DevOps (Continuous Flow) toward realizing more advanced Second Way (Continuous Feedback) and Third Way (Continuous Improvement) DevOps implementations. This part includes a discussion of “Beyond Continuous Improvement”—a look at emerging technologies shaping DevOps in the future, and how you can prepare your DevOps and yourself for the future. This part includes a discussion of how to set up an effective DevOps engineering training program that supports continuous learning of DevOps engineering skills needed to maintain and enhance DevOps.

    Part V: Appendices, Continuous Learning, and References includes materials and sources I have found most useful for engineering DevOps.

    To get a copy of my book “Engineering DevOps: From Chaos to Continuous Improvement … and Beyond,” or start reading for free, click here.

    — Marc Hornbeek

  • Predictions 2020: Infrastructure and Ops Trends to Watch in 2020

    Predictions 2020: Infrastructure and Ops Trends to Watch in 2020

    Today, modernizing systems is more than simply moving technology to a new location. It requires an IT stack of a new generation of technologies and tools to work.

    As we head into the new year, let’s take a look at the top eight trends that will shape how we will develop and deliver software. 

    Kubernetes

    Yes, it’s big and getting bigger. The pace of enterprise adoption of this leading container orchestration solution will only gain momentum in 2020. Look no further than the 2,300% attendance increase from KubeCon 2015 (500) to KubeCon 2019 (12,000). As more companies begin to see the direct financial and operational benefits to the flexibility, scalability, automation, high availability and portability of Kubernetes, the demand for developers and engineering experts in this complex software will grow accordingly. Case in point: A 2019 national job search on LinkedIn turned up 16,744 open positions for Kubernetes-related roles. Given the already large and still developing Kubernetes community, we should also see an increase in the speed and volume of feature releases. 

    Microservices

    It’s predicted that by 2022, 90% of all apps will feature microservices architectures. The growing business imperative for software engineering teams to produce and release software in ever shorter cycles—continuous delivery—has paved the way for a huge surge in microservices, the ideal architecture for CD. As enterprises continue their accelerated move to the cloud in 2020 and beyond, they increasingly prize the flexibility to try out the new technology stacks that microservices provide. All businesses want to optimize resources, minimize downtime, reduce infrastructure costs and avoid technology or vendor lock-in. In 2020, microservices architectures will continue to offer up more and better of all these benefits as the migration from monoliths picks up speed. 

    Service meshes

    The rise of microservices has led to a parallel boom in service meshes. This will only accelerate, given how integral the current class of service meshes—Istio, Linkerd, Consul, Envoy—is to the successful functioning of microservices. As a software designed to enable the thousands of microservices that make up an application to talk to each other, it’s quickly become an essential component with a vendor ecosystem poised for substantial growth. Feature-rich Istio, backed by IBM, Google and Lyft, is the leading Kubernetes service mesh, and that shows no signs of changing in 2020, especially given the relative ease of setting up and running it. If your enterprise has embarked on the journey from monolith to microservices, it will soon be crossing paths with service meshes. 

    Observability

    In the recent past, the sheer complexity of modern distributed systems has outstripped the tools designed to allow teams to see into them. Enter observability—which isn’t monitoring. Like good helicopter parents, software engineers, application developers, SREs and DevOps teams want to know and understand what their systems are doing at all times. LightStep, Datadog and Honeycomb, to name a few, are vendors poised to offer logging, tracing and metrics solutions to the rapidly growing number of enterprise teams building cloud native systems. Keep a close eye out for OpenTelemetry, an open source observability framework currently a member of the CNCF Sandbox. 

    SRE

    One of the great challenges ahead for this still-emerging field is for enterprises of varying sizes and work cultures to find a form of SRE that works. What succeeds at Google may not be the recipe for SRE implementation at smaller tech enterprises or startups. The role of SRE and the expectations that go with it remain fluid. The SRE’s constant imperative to automate will only add to the profile of critical SRE and DevOps tools such as Terraform, Ansible and Jenkins. Ponder Amazon’s Prime Day 2018 losses of up to $99 million for a clear understanding of the business-critical importance of SREs in the years to come. The job market reflects this new reality. 

    Security

    The shift-left movement in the software development lifecycle is on. The days of bolted-on post-production security are rapidly fading. DevSecOps, though still a buzz term, is here to stay, with more practice and use cases added to the theory. There are huge opportunities here for automated application security tools that support the software development workflow. 

    Then there’s privacy. The GDPR took effect last May and the California Consumer Privacy Act takes effect January 1, 2020. On top of these, there’s HIPAA and the regulatory compliance pressures on businesses in the area of security, which are already enormous—plus the immense challenges of cloud security. A 2019 Symantec survey on cloud security threats reports that 65% of businesses in the cloud still aren’t using multi-factor authentication. The same survey also notes that an astounding 85% of Symantec’s cloud customers aren’t employing security best practices. Look for businesses to tend to security earlier in the process. 

    Serverless

    It’s a boom time in serverless, with Google’s Functions, Microsoft’s Azure Functions and IBM’s OpenWhisk all offering their serverless solutions following the 2014 rollout of AWS Lambda. Look for more businesses to adopt a serverless-first approach as they upgrade legacy systems and see the substantial cost saving and application development benefits. Startups, too, will see the cost-cutting upside and the agility that serverless brings. The changes in application development and architecture in the cloud as a result of serverless are hard to overstate. With the vendor solutions now on offer, developers are freed up to do what they most like to do: run code and add functionality to their application, faster, without worrying about scaling and availability. Like microservices, serverless will see a huge upsurge in usage as the age of the monolith fades. 

    DevOps

    With the demands of cloud computing and far greater enterprise investment in dedicated teams, DevOps in 2020 is poised to make the transition from policies and principles to actual practice. The addition of baked-in security to the DevOps realm—DevSecOps—adds urgency to the automation of building, provisioning and deploying secure software. ML- and AI-driven apps have arrived, and DevOps practices will play a large role in the development workflow. The goal of zero-touch automation looms large, and this adds urgency to the need for clean data, organizational buy-in and more integrated systems. AIOps, though getting plenty of attention, is still young and its benefits to IT operations are still more theoretical than actual–but stay tuned.

    As we head into 2020, it will be exciting to watch these trends unfold. DevOps teams can expect the way we develop and deploy applications–in any architecture–to continue to evolve. By keeping a pulse on new developments in Kubernetes, microservices and other new technologies, they’ll be well prepared to bring their businesses into the new decade.

    Want to learn more about what to expect in 2020? Join us Jan. 23 for our Predict 2020 Virtual Summit  featuring discussions from some of the industry’s best and brightest offering up their visions for the future. Sign up today for this free daylong virtual event.

    — Kelsie Pallanck

  • 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

  • Synack: DevSecOps Being Accelerated by Cultural Shifts

    Synack: DevSecOps Being Accelerated by Cultural Shifts

    The 2020 State of Compliance and Security Testing Report from cybersecurity testing platform vendor Synack claims that some of the world’s largest organizations are encountering a significant cultural shift within their development teams, and that bodes well for those seeking to build DevSecOps teams. For the report, Synack surveyed leaders from more than 300 organizations representing a number of industries and verticals, including technology, government, health care, information technology and financial services. 

    According to the report, a large percentage of organizations and institutions are moving toward a rigorous, continuous testing model to ensure compliance. As part of this shift, organizations are utilizing crowdsourced security testing to achieve regulatory compliance and real security, with adoption expected to increase four-fold in 2020.

    Perhaps those companies are being driven by numerous new regulations on the horizon, including the  California Consumer Privacy Act (CCPA), PCI  DSS 4.0, New York’s SHIELD Act and  other proposed data compliance regulations. Or perhaps the shift toward continuous crowdsourced security testing is being driven by the failures some organizations have encountered with traditional security testing methods, which were performed less frequently and failed to keep up with the CI/CD (continuous integration/continuous delivery) pipelines that many organizations have embraced. 

    Simply put, Agile and DevOps application development and delivery methodologies were poorly served by the traditional, siloed security testing methodologies of the past. A realization that has driven many organizations to embrace the DevSecOps model, in which cybersecurity becomes part of the overall team, having equal standing with both development and operations team members. 

    Organizations pushing ahead with the DevSecOps model quickly realized that security toolsets and team member interactions must change to be successful. Synack’s research bears that out, and the report offers that the adoption of continuous security testing platforms is expected to increase by 4X in 2020.

    “The rapid embrace of crowdsourced security testing has happened because it is proven to work better than traditional security testing methods and addresses the ever-growing talent gap within organizations,” said Synack CTO and co-founder Mark Kuhr. 

    The report found security testing is becoming part of an organization’s normal routine, rather than a once-a-year check of the box focused only on compliance. According to the report, 44% of the organizations and institutions surveyed perform security tests on a monthly or weekly basis, suggesting that they are moving toward a continuous model, which is further enabled by crowdsourced solutions.

    The report also revealed that some 63% of organizations commonly use external vendors to identify and reduce vulnerabilities. However, 52% experience unwanted cost and complexity due to overlap in functionality from using multiple security vendors. Those two data points demonstrate that simplification provided by leveraging a single security testing platform could deliver savings. Synack claims crowdsourced security testing solutions provide 147% higher ROI than a typical pen test and can decrease the burden of testing on organizations by reducing the signal-noise ratio. 

    “This shift toward continuous crowdsourced security testing will allow organizations and institutions to have the best of both worlds by procuring technology that offers efficient and effective results while fulfilling best practice standards such as NIST 800-53 to meet compliance objectives,” said Kuhr.

    “Although we are seeing a move toward a 24/7, 365 security culture at organizations in a wide variety of industries and geographies, there is still ample room for improvement,” said Aisling MacRunnels, Synack’s CMO. “Our survey found that on average, most security tests are lasting just 20 hours. As the number of cyber incidents continues to increase, it will be imperative for decision-makers to implement security testing solutions on a continuous basis with 1500-2000 hours of testing a year.”

    Those increased testing requirements will ultimately become the foundation to build a DevSecOps culture in most any organization bound by compliance regulations.

    — Frank Ohlhorst

  • Predictions 2020: The Future of the Mobile Industry

    Predictions 2020: The Future of the Mobile Industry

    The mobile device industry continues to grow in leaps and bounds. Statistics show that, today, over 5 billion people have mobile devices and there are over 9.2 billion mobile connections worldwide. Add to these statistics the fact that the number of consumers who shop and bank online continues to grow as well–presenting hackers with increasing numbers of mobile applications and end-points to target. As developers of software that protect mobile apps from reverse engineering and hacking, at Guardsquare we have a unique purview into the mobility space, and therefore have some pertinent 2020 predictions for the mobile industry.

    Mobile Payments Apps on the Rise

    As consumers’ comfort with, and reliance on, personal technology increases, we expect to see purchases via mobile payment apps grow rapidly throughout 2020. Great news for the global economy, but the downside of this trend is it will serve to exacerbate opportunities for hackers to take advantage of mobile applications and devices that are not properly secured.

    Fake Apps Abound

    Fake apps or hidden apps have historically been a problem and we don’t see that changing any time soon. In December of last year alone, almost 65,000 new fake apps were detected among the various app stores, and we expect this to become increasingly common and problematic. Consumers need to be alert when downloading new apps and developers should be wary that fake apps can negatively affect their own reputation and their company’s. 

    Developers Beware Kotlin’s Hidden Vulnerabilities

    The new development language, Kotlin, is catching on now that it has been designated Google’s preferred language for Android development. However, many developers using the language still do not fully understand security best practices, including how to protect Kotlin code against OWASP’s well-known Mobile Top 10 risks. As with many apps written in Java, apps written using Kotlin must be protected against both static and dynamic attacks using a combination of code hardening and RASP.

    iOS Is Vulnerable Too

    We believe that 2020 will be the year in which awareness increases around the security shortfalls of iOS. Many application developers still believe iOS apps are virtually immune to reverse engineering, but, in reality, all iOS versions have already been jail-broken at some point.  We anticipate developers will take better security measures to ensure the integrity of their apps by employing a multi-layered approach to security to ensure the protection of their iOS applications.

    We continue to see the more sensitive an organization’s data, the more likely it is the mobile app will become a target for hackers. According to OWASP’s Mobile Top 10, reverse-engineering and tampering ranked the eighth and ninth most prevalent mobile security risks. Verizon’s Mobile Security Index 2019 highlights that more than 80% of organizations said they are at risk from mobile security threats, and 69% said those risks increased in the last year.

    It is our hope that, in 2020, all apps—but especially apps housing sensitive customer data—evolve from going unprotected to incorporating key security measures that protect the users and the organizations.

    Want to learn more about what to expect in 2020? Join us Jan. 23 for our Predict 2020 Virtual Summit  featuring discussions from some of the industry’s best and brightest offering up their visions for the future. Sign up today for this free daylong virtual event.

    — Roel Caers

  • Survey: DevSecOps Progress Remains Elusive

    Survey: DevSecOps Progress Remains Elusive

    Results of a survey of 103 IT professionals attending the recent DeveloperWeek Austin conference suggests that awareness of cybersecurity issues is clearly rising among developers, yet most organizations still have a long way to go toward before approaching anything resembling adoption of best DevSecOps practices.

    Conducted by WhiteHat Security, a unit of NTT Communications, the survey on DevSecOps adoption finds nearly 75% of developers worry about the security and 85% rank security as being a very important element of the coding and development process. However, nearly half of the respondents said their development teams lack a dedicated cybersecurity expert. Only 30% of respondents said they have achieved security certifications in their current or prior roles.

    More than half (57%) of survey respondents said their teams have the right application security tools in place to incorporate security into the software development life cycle (SDLC). Among those respondents who do use application security tools, a third (33%) scan for vulnerabilities daily, while 29% said they scan weekly and 20% said monthly. The remaining 18% scanned either quarterly, annually or at random.

    Also, 14% said they have not been given the proper tools to incorporate security into the SDLC and a third (33%) were unsure what their organizations provided in terms of cybersecurity tools.

    While the survey finds 57% are realizing that application security should be a key part of the SDLC, it also finds 43% of respondents still prioritize meeting their application release deadlines over security.

    WhiteHat CTO Anthony Bettini said it is apparent organizations are struggling to strike a balance between application delivery velocity and security. Organizations are under pressure to digitize more processes faster. However, that pressure can result in a lot more friction being created between developers trying to meet a deadline and cybersecurity professionals who ultimately are held accountable for the integrity of the overall IT environment, he noted.

    To bridge that divide, Bettini said a lot more work needs to be done in terms of driving the convergence of processes, people and tooling required to achieve DevSecOps. On the plus side, however, he noted within many organizations, DevSecOps is starting to supersede DevOps as a development philosophy.

    The biggest issue organizations may need to worry about as they strive to achieve that goal may be burnout. The survey finds more than half (52%) of participants have experienced burnout as a result of the intense pressures to deliver the applications on time that are secure.

    Overall, the survey makes it clear developers at the very least are willing to pay a lot more attention to cybersecurity. Compared to the way developers tended to view cybersecurity just a few short years ago, that alone represents substantial progress. The challenge organizations face now is finding a way to make it as simple as possible for developers to do the right thing from a cybersecurity perspective. There always will be the natural temptation to address a security issue later in the development cycle to meet a deadline. The trouble is that when cybersecurity issues continue to get kicked down the DevOps road, they all too often wind up becoming a major issue after an application has already been deployed in a production environment.

    — 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

  • Shifting Left – But How Far Left Do Companies Need to Go?

    Shifting Left – But How Far Left Do Companies Need to Go?

    For developers, there’s nothing more satisfying than looking at a web app or service and being able to say “I made that.” Or at least part of that. Being able to develop code that works and helps millions of people do what they need to get done is an excuse for bragging rights.

    But the opposite is also true. You don’t want to be the developer whose code inadvertently enables hackers to take control of online apps or services, for instance. There are many examples of these kinds of errors. Hackers are better and more sophisticated than ever, and no programmer wants to be the culprit in the ever-increasing number of attacks based on poor coding practices.

    Where and when do errors like these creep in? It could actually be at any stage of development. Vulnerable code could be the basis for a main module in an app, including in the very early stages of development. Once implemented, bad code travels through all stages of development, making apps vulnerable to exploits. Hence the importance of shifting left–deploying security at as early a stage in the process of code creation as possible.

    What exactly does shifting left mean in the context of code development today? Tools need to be integrated in as early in the process of development as possible, and at every stage of the software development life cycle. Today, programmers will work on code and commit their changes several times a day. They need to be able to examine that code for security issues before committing that code to the repository that other teams will be basing their work on. That, of course, is what they would do if they were checking for functional defects, and the same must be done to exclude insecure code.

    What’s the best approach to shifting left in the early stages of development? Developers need tools that can supply them with actionable information, highlighting specific issues in specific lines of code. Sort of like a “spell checker” for security risks, the tools would point out the location and issue in a line of code, and even make recommendations for how to mitigate the risk.

    With that, there are some caveats that come with tools that report risks at such a granular level. Tools should be flexible enough not to over report issues. One general problem with security tools is the possibility of false positives. Security testing tools are notorious for generating very long lists of reported issues, with many of them turning out to be false positives or issues that are not critical to fix. So, to be taken seriously and provide real value, security testing tools need to effectively highlight the high-severity alerts that you cannot ignore and also separate out true vulnerability signals from noise (i.e. false positives).

    Another caveat is that other tools need to be deployed further on in the development process. When a module is completed, it becomes a building block for other modules that will eventually be part of the full program. Testing needs to be done to determine if there are security risks when modules work together. Thus, you should not consider security as shifting left, but rather expanding left, maintaining a presence alongside the development process as it moves forward. With this kind of strategy, programmers can be sure they will have those bragging rights, proudly pointing to what they built.

    — Shahar Sperling

  • 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