devopsy.kinsta.cloud

Tag: devsecops

  • WhiteHat Security Looks to AI to Advance DevSecOps

    WhiteHat Security Looks to AI to Advance DevSecOps

    WhiteHat Security is now embedding artificial intelligence (AI) into the application security review services it provides, as part of an effort to advance adoption of DevSecOps processes.

    Joseph Feiman, chief strategy officer for WhiteHat Security, said the biggest resistance factor to DevSecOps has been the amount of time it takes to test applications for vulnerabilities. By injecting machine learning into that process via a suite of WhiteHat Sentinel Dynamic tools, which are being made accessible as a software-as-a-service (SaaS) application, developers will be more inclined to conduct security reviews as part of an integrated DevSecOps process, he said.

    The AI engine identifies vulnerability patterns in a code-based data lake of 95 million identified vulnerabilities that WhiteHat Security has identified via its dynamic application testing service (DAST). WhiteHat Sentinel Dynamic identifies known vulnerabilities in seconds, Feiman said, and any anomalies indicative of potential unknown vulnerabilities are then reviewed by human WhiteHat Security cybersecurity experts.

    Feiman said DevSecOps is going through a period of disillusionment because security reviews of code are taking too long. AI technologies represent an opportunity to reignite interest in DevSecOps by giving developers more control over an application security review process that no longer slows down development.

    In addition, WhiteHat Sentinel Dynamic enables developers to learn about their potential mistakes without necessarily requiring them to disclose them to the entire DevOps team. Any humiliation a developer might experience is avoided when the developer conducts the security review prior to committing code. IT security teams are still in charge of creating the policies that need to be implemented, but processes associated with implementing those policies make a decidedly shift left to the developer, he said.

    Feiman noted that the rise of AI within DevSecOps processes may help alleviate some of the current chronic shortage of cybersecurity expertise. There will always be a need for human cybersecurity researchers to train AI models what to look for as new vulnerabilities are discovered. But algorithms never take a day off or decide to abruptly quit because they suddenly got a better offer.

    It may take a while for IT organizations to completely trust AI engines to scan code for vulnerabilities. But currently many applications are not being reviewed at all because any time set aside to conduct that reviews is being eaten up by an application development process that has fallen behind schedule. Too many developers would still prefer to take a chance on a breach than be reprimanded for delivering code late, especially when there’s a chance to address vulnerabilities that might get discovered in the next scheduled release of a patch. WhiteHat Security is making the case for eliminating much of that risk by making it feasible for developers to quietly address vulnerabilities long before an application is deployed in a production environment.

    There’s no doubt that AI soon will be employed to automate large swaths of cybersecurity. But it may turn out that the most effective place to apply AI from a cybersecurity perspective early in the DevOps process as possible.

    — Mike Vizard

  • DevSecOps: Where DevOps and Security Meet

    DevSecOps: Where DevOps and Security Meet

    Catching up with three IT leaders on the role of security in the changing world of DevOps

    The DevOps methodology as a software and engineering culture goes back nearly 10 years—Patrick Debois coined the term when he named a Belgian software conference “devopsdays.” Since then, the movement has taken on a mind of its own, turning into the go-to strategy for enterprises the world over aiming to accelerate their development timelines and deliver better products faster.

    In the shifts and changes that have happened over the last decade, one has been the idea of “DevSecOps,” or the intersection where security practices and DevOps transformations meet. Recently, at the DevOps Enterprise Summit 2018 (DOES18) event in London, several key players in the DevOps world sat down to take a deep dive into the world of DevSecOps. In the following article, we’ll review some of the key points discussed by Ilkka Turunen, head of Solutions Architecture at Sonatype; Zane Lackey, founder of Signal Sciences; and Margo Cronin, senior solution architect for Amazon Web Services during our panel discussion at DOES18.

    The first point of the discussion centered around the role of security in DevOps, and how the name “DevSecOps” should never make you think security is secondary.

    “I’ve never been crazy about the term DevSecOps, because it’s like ‘Sec’ is an afterthought,” said Turunen. “You know, we were squeezing it in between Dev and Ops, the last kid that got on the bus, and we’re like, go on, just sit in there. For all of us, security is the first priority, the top job—’job zero,’ we sometimes call it. And therefore, for DevOps, it actually understands that security is key, and is the first thing that you do.”

    Turunen pointed to recent changes brought on by GDPR that have made privacy one of the pillars of software development, and how this has brought about further emphasis on security in DevOps transformations. In this new world of GDPR regulations, it’s not limited to just data portability and data breech notifications, but truly goes into “privacy by design.” As such, security is paramount.

    Later, the conversation turned to the idea of how one can create a culture where everyone thinks of themselves as a security practitioner, a seemingly necessary step to having foolproof security practices. The answer lies in creating an organization where security is part of the fundamental culture—a similar cultural change as to what happened around testing.

    “So if you think about testing 10 years ago, it was literally people running from test execution plans, and gradually they changed from that to becoming writers of tests, people that write the automatic-execution, help people, help the floor become more efficient at testing for themselves,” said Turunen. “Teaching them unit testing, all these other frameworks. So I feel like we’re at the brink of a similar kind of change. I think it’s a mixture of both incentives and psychology, and just changing roles.”

    Lackey puts it even more simply—that good engineering just goes hand in hand with good security.

    “The best way I’ve ever seen, like the highest performing organizations view it, is security is a subset of good engineering. In the way that resiliency is, reliability is, quality is, performance is, is a subset of good engineering,” said Lackey.

    Finally, the conversation turned to the role of public cloud service providers and how they can help uplift security for software organizations. For Cronin, the idea of machine learning holds a lot of promise for increasing security.

    “You now have services that can scan your landscape and say do you know these large files contain client identifying data, do you know you have keys there?” said Cronin. “And then you have services where you can then change that behavior automatically. But I think that’s where we’re going to see cloud service providers become a lot more active. You know, using machine learning to harden your production landscape before you actually even go to the security operators.”

    While the world of DevOps is constantly evolving, growth in highly regulated and compliance-oriented industries—coupled with increased global concern over data privacy—have put increased emphasis on incorporating security throughout the software pipeline. To learn more about how these DevOps experts view DevSecOps, and how they are making security a bigger focus in their organizations, you can watch the entire discussion on DevOps TV.

    Bonus: You can also watch Cronin’s DOES18 presentation on “Security Automation at Scale” and Lackey’s presentation on “How You Can Use DevOps to Make You More Secure.”

    And be sure to join us next time at DevOps Enterprise Summit Las Vegas, Oct. 22-24, 2018!

    — Alan Shimel

  • GDPR and Data Leakage: How Semantic Graphing Can Help

    GDPR and Data Leakage: How Semantic Graphing Can Help

    Many of the hallmarks of modern application development that drive efficiencies in the software development life cycle (agile, CI/CD, microservices, cloud infrastructure, open source libraries and third-party APIs) also create significant data leakage risks. Meanwhile, the EU’s General Data Protection Regulation (GDPR), which took effect May 25, creates a need to protect more types of data than ever before and comes with the strongest penalties for non-compliance: €20 million or up to 4 percent of a company’s global revenue.

    Preventing Data Leakage Getting More Difficult

    There are three primary reasons why data leakage has become more challenging for developers: complexity, speed and external services.

    Applications themselves have become more complex as organizations adopt microservices architectures. While this enables developers to be more efficient, it also often leads to more siloed views of the application while the data flows become more complex. For example, how many organizations understand  every entry point, exit point and handling of variables across every microservice in their broader application? And, organizations that adopt open source to increase efficiency by not having to reinvent non-differentiating code often fail to comprehensively understand the third-party code in depth. This makes understanding data flows even more difficult.

    The increasing pace of releases exacerbates complexity issues. Many organizations now release monthly, weekly or even daily. With less time to focus on anything beyond meeting feature deadlines, mapping data flows often becomes an afterthought. Furthermore, even if an organization is able to thoroughly map their data flows for any given point in time, the rate of change makes it impossible to stay on top.

    As organizations adopt third-party services for key functions such as code repositories, logging, databases and analytics, the consequences of leaking data become severe. For example, Uber leaked AWS credentials into GitHub, from which bad actors were able to initiate an attack that lead to 57 million records being compromised—simply by logging in.

    Why GDPR is Different

    GDPR is a significant expansion of previous data protection regulations in a number of ways. Unlike the Health Insurance Portability and Accountability Act (HIPAA) and Payment Card Industry Data Security Standard (PCI DSS) in the United States, GDPR applies globally and across industries. Any company that holds or processes data on an EU resident is subject to the regulation. Cloud-based software is inherently more global, and many U.S. or Asian-based organizations have users that are EU residents.

    GDPR expands the definition of what needs to be protected in a big way. HIPAA and PCI DSS formalized rules around protecting healthcare and credit card data. However, GDPR expands data that must be protected to include anything that can be used to identify a person—anything from a name, a photo, an email address, bank details, posts on social networking websites, medical information or a computer IP address.

    And GDPR has real teeth. Companies can be fined up to 4 percent of their annual global revenue or €20 million for major breaches and 2 percent of their global revenue for minor breaches. Given the global nature of modern cloud applications, the potential impact of GDPR is far-reaching.

    Traditional Approaches to Preventing Data Leakages

    Traditional approaches to preventing data leakage have been focused primarily on acting as a proxy between the application and the rest of the world. In such a position, the proxy can attempt to filter data and look for patterns. These approaches are outside-in. They do not attempt to understand the application itself; rather, they inspect traffic flowing from the application without context.

    First, let’s clarify that despite the similar sounding name, preventing data leakage is not the same as data loss prevention (DLP). Traditional DLP vendors such as Vontu (now Symantec) and cloud access security brokers (CASBs) are solving a different problem. They are an IT-centric solution to preventing malicious or accidental data breaches that are typically driven by end-users moving documents via email or file sharing. These tools aren’t designed to prevent the applications themselves leaking data and they are of little use to developers.

    The more application-specific attempts to identify data leakage have been via web application firewalls (WAFs). As proxies, WAFs often employ pattern matching techniques such as looking for 16-digit numbers on the assumption it may be a payment card, keyword matching, fingerprinting and other statistical content analysis techniques. In practice, these methods are ineffective because they create far too many false positives. Furthermore, encryption is problematic in that the WAF either can’t inspect the data or a man in the middle decryption must be set up, which is computationally expensive and can add latency. Latency may not matter for traditional DLP solutions monitoring email, but it’s vitally important to developers managing cloud applications.

    One traditional method for identifying data leakage that does take and inside-out approach is taint tracking, which evaluates pre-existing binaries. In reality, taint tracking is impractical because of excessive performance costs and numerous false positives due to taint proliferation (transitively from application to web framework to kernel).

    Taint and information-flow analysis approaches track the flow of data through the program, assuming that the data originated from untrusted sources. Sources are where such data flows enter the program, and sinks are where they leave the program.

    Several publications define sinks informally as “data that leaves the system,” which is too imprecise to train a machine-learning based classifier; such classifiers are only as good as their training data.

    Dynamic taint tracking by plain instrumented emulation is extremely expensive and tend to slow systems. Such a slowdown is unacceptable in practice and significantly hinders the adoption of dynamic taint tracking systems for everyday use. Such taint proliferation can substantially impair the performance of the running system.

    Mapping Data Flows with Semantic Graphing

    To truly prevent data leakage, you must first map data flows. You must understand the building blocks of the application, including its security DNA. However, the difficulty comes from balancing comprehensiveness with speed. Simply put, to account for all possible leakages in a rapidly evolving application you must automate.

    Semantic graphing is based on a simple observation: There are many different graph representations of code, and patterns in code often can be expressed as patterns in these graphs. It is a graph of graphs that, for the first time, enables automatically creating profiles that understand the context of an application. Semantic graphing is language-neutral intermediary representation designed for code querying, which focuses on what the program is designed to do, what it is not supposed to do and how it functions. Because semantic graphing identifies which variables are sensitive and how they flow across each microservice, it then becomes possible to visually represent data paths and identity leakage/violations.

    In this instance, we seek to understand data flows and prevent leakages. However, the ability to understand an application’s context in code is fundamentally the foundation for DevSecOps. AppSec remains manual primarily because humans must apply the application’s context either through configuring rulesets or wading through false positives, both of which are impossible tasks. Beyond just data leakage, semantic graphing has the potential to deliver security at the speed of DevOps.

    — Chetan Conikee

  • Implementing DevSecOps in the Mainframe-Driven Enterprise

    Implementing DevSecOps in the Mainframe-Driven Enterprise

    DevSecOps is emerging as an important trend in corporate IT. It makes sense. With each passing day more applications serve a larger user base. Whereas in the past the typical business application was accessible only from within the confines of an enterprise’s internal network, today, the software-as-a-service (SaaS) paradigm enables millions of users work with a single application.

    In the SaaS paradigm, a single application will service a number of companies and give each user in the company access to data and functionality based on a given company’s subscription plan. Take Saleforce.com for example: There is but one Salesforce.com providing service to thousands of companies worldwide, each with one to thousands of employees. Each company and each employee within a company will have particular access rights to the application. A paradigm in which there is one application servicing millions, perhaps billions of users requires a comprehensive approach to security. The slightest breach can result in havoc. Imagine what would happen if a SaaS application contained a flaw that allowed a company to see the financial data of its competitor that also subscribed to the SaaS.

    Given that the internet is the de facto network for all worldwide, today’s security concerns go way beyond restricting network access. Keeping bad actors away is becoming more difficult all the time. The sad fact is that a seemingly good actor can turn into a bad actor instantly and wreak havoc not only on the servers with the network—as is the case of a DDos attack—but on the application layer as well. In fact, according to IBM, an enterprise’s network layer is half as vulnerable as the application layer, yet more money gets spent protecting the network.

    This is an eye-opening fact and one not on the minds of most application developers. But, it might be, if developers had the benefit of the expertise and ongoing guidance required to implement bulletproof security at the application level.

    Which leads us to the mainframe.

    In today’s world of modern, web-based cloud computing, the mainframe is a major player. Seventy percent of corporate data lives on a mainframe. Also, now that the Linux operating system is pervasive in the mainframe environment, enterprise-level application developers can—and do—write Java, Python and NodeJS code for the Big Iron just as they do for X86 commodity environments. Technologies such as IBM’s z/OS Connect EE and StrongLoop make it possible to use an industry-standard specification such as OpenAPI to expose mainframe services as REST API without a lot of low-level fiddling around.

    This is good news.

    The bad news that application developers are just not that adept at security best practices. They don’t have the experience of a CISSP professional who has spent years, if not decades, in the trenches battling the bad guys in cyberspace. But that was then and this is now. Today we have DevSecOps.

    DevSecOps is the next generation of IT transformation. The goal of DevOps is to create an IT culture that is unified, automated and self-correcting. DevOps combines development and operations into a single organization focused on creating and deploying quality software at ever-increasing rates. DevSecOps adds security into the mix. The scope of DevSecOps activity is not confined to software development for commodity-based X86 servers and mobile devices. DevSecOps is intended to apply across all facets of the enterprise, from mobile to mainframe.

    DevSecOps is about a lot of things. It’s about the adoption of tools such as IBM’s AppScan, a tool that allows an enterprise to implement and monitor a variety of tests (web, mobile, dynamic, static and interactive) in a unified dashboard. It can include leveraging Secure Service Containers to ensure external security and safety from insider threats.

    DevSecOps is about putting in place a set of policies, along with appropriate operational checks and balances, that ensure that the enterprise follows security best practices at all times. It’s about following practices that go beyond episodic security testing. This means continuously analyzing the IT infrastructure to identify vulnerabilities as well as defining ways to mitigate risks and prioritize prevention activities accordingly. It means making compliance to regulations such as GDPR, PCI-DSS, PA-DSS, ISO 27001 and ISO 27002, HIPAA, GLBA and Basel III  an enterprise-wide responsibility, not just something that’s siloed away to the Compliance Department.

    DevSecOps is about acting proactively by using automation to rigorously inspect all code to uncover potential hazards. It means using HTTPS as the default protocol for public-facing URLs. It means making sure that all third-party components are built from source code when possible—and, if building against source is not possible, ensuring third-party components and libraries are certified safe by an accepted authority.

    DevSecOps is about a lot of things, but there is one principle that overrides all others:

    When it comes to DevSecOps, the most important principle to follow is to make sure that a security expert is a starting member of any team involved with making software for the enterprise.

    It doesn’t matter if the company is 30 years old running on a mainframe or 30 days old using native cloud services, there must be security experts as part of its development work from the start.

    This may sound obvious, but it’s easier said than done.

    It’s not a new challenge. It took the enterprise a long time to get QA personnel involved at the start of development process. Before the DevOps/Agile sensibility took hold, QA personnel showed up at the end of the release cycle, well after code was hardened.

    The same is true of release personnel. Before DevOps, release management was given some code and told to just get it out as soon as possible. There was limited knowledge as to what the code was about or the potential impact it might have on the infrastructure. As a result, weekends were spent in war rooms struggling to deploy code that was sparsely documented and mysteriously tested. You can bet that once release management showed up at the first project planning meeting, things changed.

    Now, with the emergence of DevSecOps, it is security’s turn in the tumbler. Security has always been an important part of enterprise IT. The number of compliance regulations on the books attest to the fact. However, security was usually the responsibility of the Compliance Department more than part of the IT organization overall. For many companies, the only time security ever came to the forefront was during audit time. As a result, security practices were more reactive than proactive. And, for many companies, they still are—think back to reactions to the Equifax and Target breaches.

    However, the success of DevOps has not gone unnoticed. The standard features of DevOps—unifying groups toward a common purpose, implementing automation whenever possible and using sprints and retrospectives to facilitate fast releases and address shortcomings quickly—has had positive results. Forward-thinking companies understand that DevOps works, and its successor, DevSecOps, will work provided the essential principle is followed: Make sure security experts have a seat at the table from the beginning.

    For many companies this means transforming from a culture of isolated silos in which managers serve as gatekeepers and powerbrokers to one of unified open groups in which a manager’s job is to assemble self-directing groups and to make sure that all the right people are involved from the beginning of a project. It’s a fundamentally different way of doing business.

    When it comes to realizing the promise of DevSecOps, tools are important. So are processes. But, the most important thing is to make sure that security is built into the fabric of the development life cycle, from start to release.

    DevSecOps will fill the missing link in the software development chain. It has to. There is little choice otherwise. Adhering to the most important principle of DevSecOps—to have security involved as an equal player from the beginning of the process—will go a long way toward ensuring that all software, from mobile and IoT to native cloud installations and mainframe instances, will provide the degree of safety and reliability required to serve the needs of users and companies in the digital economy of the modern world responsibly.

    — Bob Reselman

  • When It Comes to Mainframe Computing, There’s More to Containers Than Containers

    When It Comes to Mainframe Computing, There’s More to Containers Than Containers

    When people in the DevOps world hear the word “containers,” most of the time they imagine the lightweight, standalone, executable Docker binaries that have become commonplace in today’s cloud infrastructure. It might come as a surprise, however, that the world of mainframe computing not only supports traditional Docker containers, but also expands the concepts of isolation and safety into another type of containerization technology called IBM Secure Service Container. For companies running Linux on an IBM Z, Secure Service Container brings a new dimension of security to mainframe computing.

    Mainframe computing already offers a lot of power that is difficult to match in a commodity x86 environment. For example, the IBM z14 mainframe can store up to 32TB of memory. It has a 10-core z14 CPU that can run at speeds up to 5.2 GHz, which is considerably faster than the ~4 GHz of a 4-core Intel i9 processor. With this power, the mainframe can perform 30 billion RESTful transactions a day running Node.js and MongoDB in standard Docker containers. Mix in the versatility and code reuse that running Linux on a mainframe provides, and you get a level of computing power that’s hard to ignore.

    In terms of application development, putting Linux on a mainframe allows applications written in popular languages such as Java, Python or Node.JS to run on an IBM Z system just as they would in a data center full of x86 machines. And the total cost of ownership of a mainframe can be surprisingly  competitive when compared to a commodity system.

    Despite these  benefits, Linux on a mainframe faces many of the same security challenges that other platforms have, both in terms of hardware and software intrusion. The difference is that IBM Z is more secure out of the box and offers a number of additional technologies to address these challenges—100 percent application data encryption, isolated workloads for multi-tenant environments, full lifecycle encryption key management with encrypted keys and tamper-responding cryptographic hardware. But many times, safety boils down the security acumen of the system administrator and the overall security discipline instilled within an organization. Some organizations have excellent security practices. Others are challenged. Regardless of the degree of competency, it is difficult  to lock up a box in a bulletproof manner. This is where Secure Service Container technology comes in to play.

    Working with Secure Service Container

    Secure Service Container combines hardware virtualization, applications and data into a secure, encrypted “container” (partition). The encryption keys are protected in the Secure Service Container partition. Should a key become compromised or attempts are made to tamper with the keys, the Secure Service Container will invalidate the key and the encrypted contents will become inaccessible.

    Once the Secure Service Container is deployed (via the physically secure hardware and firmware), everything inside it is fully encrypted. The boot sector becomes tamper-proof and memory access is disabled. Also, access to the system via SSH is also removed. As a result, hardware and operating system SysAdmins have no direct way to tamper with the environment beyond RESTful interfaces for communication and management.

    Using SSH to administer a system leaves a lot of opportunity for catastrophe: While Linux allows you to limit access to commands according to group and user permissions, just one unsecured executable mistakenly installed in the environment can cause a mishap.

    On the other hand, the only way to access an Secure Service Container-enabled environment is via a set of APIs. Each piece of administrative functionality associated with the Secure Service Container API is represented as an endpoint with an access method. Thus, the advantage of secure access via an API is that work is done over a common interface on a task-by-task basis. A distinct security policy can be applied to each endpoint and associated access method. This is a very fine-grained security model.

    Using an “API only” approach for access means that for all intents and purposes, the system is completely locked down. Even root users and SysAdmins are denied access that is not granted according to the security policy on the given endpoint. Thus, “Snowden-type” attacks are prevented.

    The HSM—the physical device that encrypts and protects keys—is certified to FIPS 140-2 Level 4, which is the highest security standard defined in the Federal Information Processing Standard. Also, the individual Secure Service Containers are isolated to EAL5 and higher levels, giving you near-air gap isolation between containers to ensure that side-channel attacks won’t work. This is industrial-strength security that is designed to meet the needs of extremely security sensitive environments such as banks, power grids, the Atomic Energy Commission and the CIA. Secure Service Container is serious technology for serious enterprises. However, Secure Service Container can benefit any company that wants to dive  into the world of mainframe computing, the costs of which can be surprisingly affordable.

    A New Way of Thinking

    When most people think about mainframe computing, they think of large companies with big budgets to spend on high-priced  hardware. While this might have been the case in the past, today mainframe technology is well within the grasp of smaller companies. Today’s mainframes can be as much as 92 percent lower for total cost of information compared to their x86 competitors. And when you take into account the added agility, scale and security, setting up an on-premises cloud installation using an IBM mainframe as opposed to a rack of x86 machines seems very reasonable.

    The mainframe offers significant benefits besides cost, particularly when Secure Service Container technology gets added to the mix. To start with, running Linux on a mainframe creates a common playing field in terms of application development. Most Linux-based application code can run on a mainframe as well as on a PC. This means that a single Java developer can leverage his or her expertise to write for a variety of environments—PC, Android or mainframe.

    Security Risks by the Numbers

    ●      Cybercrime damages will cost the world $6 trillion by 2021

    ●      The average cost of a data breach in 2017 was $3.6M

    ●      60% of the victims of victims of cyber attacks run the risk of being put out of business

    ●      Every 14 seconds a business will fall victim to a ransomware attack

    ●      Only ⅓ of enterprises are security testing containers intended for production

    The mainframe also offers very large storage, incredibly high computing capability and a unified environment. Both applications and database can live within the same box, diminishing network latency and increasing overall processing speed.

    Secure Service Container technology make security both robust and easier to manage. The “API only” access approach to system administration makes support a secure, standardized undertaking. From a DevOps perspective, the standardization provided by the “API only” approach is easy to automate and you avoid having to accommodate the peculiarities that go with system administration at a lower level of operation.

    Finally, as mentioned above, Linux on IBM Z supports Docker. Integrating mainframe resources with the Docker ecosystem enables high-powered, high-volume, ephemeral computing within a single machine installation. A single Linux on IBM Z installation can support up to 1 million Docker containers. And, because these containers reside on the same machine, they can take advantage of co-location with other mainframe workloads and minimize the impacts of external network latency. As anybody who has worked with a distributed architecture can tell you, a containerized microservice is only as good as its availability. Putting all containers on a single computer reduces the risk of interservice communication failure significantly. This is a very big deal—especially considering the 99.999 percent uptime of IBM Z.

    Putting It All Together

    Containers are fast becoming the foundation of modern cloud computing. There’s more to  containerization however, than creating instances of Docker images. The concepts behind containerization have broad application well beyond commodity based computing. Secure Service Container combines the best practices intrinsic to both hardware and software security to create a Linux-based environment that makes mainframe technology a first-class player in the world of modern cloud computing.

    Given the decreasing costs and increasing benefits of technologies such as IBM Z and Secure Service Containers, mainframe computing can become a significant asset to any company. All that’s really required is taking the time to understand the power available and explore the possibilities at hand.

    Learning More

    You can learn about about Linux on IBM and Secure Service Container at the following resources:

    — Bob Reselman

  • Speed and Security Can Coexist in Mainframe DevOps

    Speed and Security Can Coexist in Mainframe DevOps

    DevOps teams face a constant tug-of-war in their daily work, balancing the need for speedy rollouts of high-performing (fast, reliable) applications that are secure also. If the team moves too quickly, an overlooked security vulnerability may make its way into production. If the team is not nimble enough to identify those security gaps, it can slow down the entire development process, hampering organizational agility.

    The need to strike this critical balance has led to the rise of DevSecOps, or the integration of security into DevOps best practices through automated techniques. Much has been written about the importance of bringing the mainframe fully into the DevOps fold, evolving the platform to keep pace with the speed of modern software development. But what about the security of mainframe code and mainframe data specifically—incorporating the mainframe into the third leg of the DevSecOps stool?

    A recent survey found that 72 percent of customer-facing applications are completely or very dependent on mainframe processing, which means there’s a lot of personal, sensitive information flowing through mainframe code and into mainframe data repositories. The mainframe platform itself is the most secure system on the planet, due in large part to its unique function and design. IBM’s new pervasive encryption is a groundbreaking development for enhancing data security on the mainframe even further, enabling data at rest (in traditional VSAM files and databases) as well as in transit to be encrypted at a pace of 12 billion transactions per day, all with no impact on system throughput speeds.

    Bulletproof Mainframe Security

    Still, highly personal and sensitive data can be compromised if steps aren’t implemented to ensure mainframe code and data are as inherently bulletproof as the supporting platform. What steps can help mainframe users achieve the conflicting goals of fast mainframe development combined with superior security?

    Privatized Test Data

    Speed is critical in all aspects of DevOps, including application testing. Mainframe transactions are the heartbeat of modern applications, making testing critical to ensure these components are working properly. Many organizations prefer using live, mainframe-based production data in testing, as this provides the most realistic view of how an application will work “in the wild.” However, in the rush to pull testing data, many organizations have fallen into sloppy practices including failing to disguise this data, which puts sensitive, personal data at risk of exposure. Companies needing to comply with the EU’s Global Data Protection Regulation (GDPR) face another risk—non-compliance—since they may be using customer data for a purpose (application testing) beyond that for which it was originally procured.

    Mainframe users can continue to use real production data in application testing, but they need to take special steps such as using pseudonism, which entails randomly scrambling certain values in a database (for instance, names) so that real customer names are disassociated with other personally identifiable information such as addresses or credit card information. Making it reasonably difficult to associate individual customers with their personally identifiable information is one way to achieve a higher level of information security for production data used in testing. Creating privatized application testing data sets must be a repeatable, automated process that allows testers to quickly get access to the test data they need to expedite testing processes.

    Credentialed User Auditing, User Role Management

    The DevOps concept entails greater frequency of code changes, which naturally leads to more testing and more developers and testers accessing data and applications. Unfortunately, the involvement of more team members, all working at a faster pace, can sometimes lead to carelessness and inadvertent and unintended security risks. There are techniques available now that allow organizations to see exactly what credentialed users did and what data was accessed. Some may view this as bordering on “Big Brother” type of behavior, but the fact is, with so much sensitive data continuing to reside on the mainframe and growing compliance requirements (GDPR, for example), such surveillance is vital to protecting both the enterprise as well as workers, the majority of whom have no ill intention.

    However, user auditing comes with an important prerequisite, and that is better management of user roles. “Least privilege” is a long-held security best practice of restricting access for users only to those resources absolutely required for them to do their jobs. The challenge is when workers change roles, they often are not removed from their previous role definitions and privileged access points, and simply given new ones. Since they may no longer need their old credential sets, this violates the least privilege concept and represents a significant security threat that auditing may not be able to fix. The benefits of auditing—in terms of fostering faster testing and overall development without compromising security—depend on strong user role management.

    Automated Rollouts/Rollback

    Automated rollouts make the process of releasing code into production faster and more efficient. A dwindling pool of mainframe specialists means that in many cases, workloads spend significantly more time being queued up waiting for available resources, than they do actually being implemented. Removing the need for a developer to manually push new updates into production can be a major benefit in speeding up the mainframe cog. However, approval layer and audit capabilities must be built-in to ensure code security has been tested and verified and the source of any potential problems can be traced back quickly and accurately. Automated rollback functionality is also critical in the event that a security flaw does make its way into production, by enabling developers to immediately roll back to a previous version of the software until the flaw is fixed.

    Much progress has been made in recent years when it comes to evolving the mainframe for DevOps, as several examples can attest. But given the sensitive personal data that is often running through, and residing in, mainframe code and data, the scope must expand to DevSecOps, and the steps described here represent a solid initial plan for getting there. Organizations that do this will enjoy the maximum benefits derived from a highly agile, secure mainframe environment delivering unparalleled scalability and reliability for its digital transformation initiatives.

    — John Crossno

  • Best Practices for Application Security Testing in the Era of DevOps and AI

    Best Practices for Application Security Testing in the Era of DevOps and AI

    Application security testing is no easy feat. And yet, it’s usually the first topic that most articles about application security address. The reasons are simple: As the pace of application development techniques (and their inevitable vulnerabilities) evolve, AppSec personnel have found themselves caught between the desire to keep pace with their management of security testing requirements and their ability to allow the developer teams to operate in the modern, fast-paced ecosystem of DevOps and artificial intelligence.

    To better understand the best practices for conducting AppSec testing in the era of DevOps and AI, it is important to first appreciate the technologies available to us, that allow us to do so.

    At the heart of the modern application security testing,  there are five main technologies to be aware of:

    1. Static application security testing (SAST)
    2. Dynamic application security testing (DAST)
    3. Software composition analysis (SCA), third-party code
    4. Fuzzing
    5. Penetration testing

    These five technologies account for the bulk of most of the activities around application security testing. However, many aspects of application security testing are rapidly changing, including efforts to incorporate automation and artificial intelligence into the equation.

    By including automation or AI, for example, code testing is allowed to be released in rapid fire sequence, with production use approvals baked inline through automated logic and decision-making. This idea of continuous integration/continuous delivery (CI/CD) can lead to a widening of fractures between the security and development teams. Therefore, DevOps users today need the ability to program their code and test it through automated code scanning techniques before pushing the code into secure staging environments.

    To successfully conduct application security testing in today’s era of advancing developer operations through automation and artificial intelligence, there are three critical best practices to keep in mind.

    1. The Earlier, the Better: Introduce appSec testing into the software development life cycle early on for maximum results: Regardless of the type of testing being conducted, waiting until the very end of the development process will only create more work. Users will either end up with more bugs than they could feasibly fix or find themselves a part of an overworked AppSec team as they attempt to document and deliver on discovered vulnerabilities and code flaws. Statistically speaking, code changes that happen later in the development life cycle are also more costly to the business.
    2. Conduct testing of business-critical applications as often as possible: When deciding which assets are next in line for application security testing, one should consider the applications and systems that are of critical business value to the organization’s revenue stream. Think of these systems in particular as the “crown jewels” for the majority of attacker motives, since they define the amount of money a given organization will procure for that day and, if attacked, could disrupt the business in myriad other ways.
    3. Test for third-party code security and interoperability flaws as you would your own software: The growing complexity of modern applications means there is a need to leverage open source or third-party components. As this is the case, these components must also receive the same level of scrutiny as the applications in one’s own enterprise. All third-party code referenced in the software delivery process must also be checked by performing software composition analysis for security and interoperability flaws.

    While the pace and techniques for AppSec testing will undoubtedly continue to advance, and while there are some AppSec testing techniques that may never become obsolete, it is imperative to ensure that one’s system for maintaining application security testing always adheres to the best practices to preserve a secure software environment for the future.

    — Anthony Lauro

  • DevOps: Making the Development Cycle More Secure

    DevOps: Making the Development Cycle More Secure

    The promise of secure DevOps can be realized through security technologies such as dynamic authorization

    Fundamentally, DevOps is all about speed and agility. Customers expect companies to deliver and update applications at an accelerated pace and businesses must adopt modern technologies to meet customer expectations. With DevOps, organizations can implement a continuous development and deployment cycle to reap a multitude of benefits.

    Not only can organizations operate and evolve applications at high speeds with DevOps, but they also can do it more cost-effectively by automating all steps involved with software construction to avoid manually deploying code or configuration changes for each application.

    While speed and security are not necessarily enemies, if the security or access control technologies deployed are not in tune with a continuous deployment flow, the full promise of DevOps will not be realized. Waiting until the end of a development cycle to review security opens organizations up to security issues that could have been more easily resolved had security controls been implemented in the first place. Late discovery of security concerns also slows down the process—which is, of course, counter to some of DevOps’ primary objectives. To obtain the full potential of DevOps, organizations must ensure that security controls, such as externalized authorization, are an integral part of the security process from the very beginning.

    The Importance of Security Controls

    Security controls can proactively and consistently address different security aspects across the enterprise. A continuous integration/continuous deployment (CI/CD) cycle is a critical piece of the DevOps process; it implies that the application environment is potentially changing at any moment and possibly on a frequent basis. With constant changes to the production environment, it is critical to ensure that security controls are a part of this process—hence, the term “DevSecOps.”

    If security processes are not part of the overall process, then you risk the chance that security controls have not been vetted properly or consistently enforced with every new release or new application/API/microservices. However, the security controls must also conform to a DevOps approach, meaning they must fit into a model that is streamlined via automation to be deployed and managed in a manner much like modern-day applications.

    Conforming to a DevOps approach can have different perspectives. What we are focusing on here is to suggest that security and identity services should be deployed and managed in the same manner as your application code. Cloud-native capabilities, clearly defined interfaces, REST and JSON enabled interfaces and containerization are some of the characteristics that make security and identity services look and feel like the business applications and services.

    Integrating the Right Security Controls

    To realize the full benefits of DevOps, organizations must deploy security or identity management technologies that are in sync with a continuous deployment/integration cycle. If identity and access management (IAM) systems cannot be deployed and managed in the same manner as your APIs and microservices, then it makes the DevOps process more cumbersome and less streamlined.

    One technology to consider is externalized dynamic authorization delivered with attribute-based access control (ABAC). With dynamic authorization, users are authorized access to resources based on attributes. Authorization is then determined dynamically at runtime by evaluating centrally managed rules and policies.

    With dynamic authorization, you can automate policy changes the same way you can automate code changes. In addition, the ABAC service itself can be managed like a microservice, giving it the same flexibility, deployment and automation characteristics as your application microservices. Ultimately, the life cycle of redeploying the application and security components can be fully automated. Similarly, any changes to policies can also be part of the automation process. Furthermore, you can automate the activation of additional authorization servers for peak load conditions and remove them when less capacity is required.

    With an automated approach you can relieve pressure on developers, because they no longer will have to write security rules into their code. In addition, access rules are enforced consistently across applications, APIs, microservices and data resources, reducing the risk of overexposure to information and security breaches. This also means that your developers can spend their time on business functionality, not worrying about access security.

    Security technologies such as dynamic authorization are a critical part of the DevOps process. With dynamic authorization embedded directly into the development cycle, organizations can automatically address a wide variety of security aspects across the enterprise and ensure a continuous and secure development cycle.

    — Gerry Gebel

  • DevOps Chat: How Cyxtera Uses DevOps to make AppGate SDP Better

    DevOps Chat: How Cyxtera Uses DevOps to make AppGate SDP Better

    In this DevOps Chat, we speak with Kurt Glazemakers of Cyxtera. Kurt is the CTO of the Software Defined Perimeter group within the security and analytics group at Cyxtera. Kurt discusses how his group uses a DevOps approach to making AppGate SDP better and how that, in turn, makes it better for DevSecOps-enabled organizations.

    In case you are unfamiliar with Cyxtera, it is the company that resulted from the acquisition of 57 data centers and the co-location business of CenturyLink (which then used that money to complete its acquisition of Level 3), plus the acquisitions of Cryptzone, Catbird, Easy Solutions and Brainspace. The company brands itself as the “secure infrastructure company” and is now one of the leading co-location players globally. Managed by most of the former senior management team at Terremark, which itself was acquired by Verizon (Oh, what a tangled web we weave in the tech world), Cyxtera is now something like a $2.8 billion business.

    During our chat, Kurt gives us some great insight into how DevOps, automation and CI/CD have helped make Cyxtera’s product better. As usual, the streaming media of our conversation is below, followed by the transcript.

    Audio

    Transcript

    Alan Shimel: Hi, everyone, it’s Alan Shimel and you’re listening to another DevOps Chat. Today’s DevOps Chat has a distinctly DevSecOps/security bent to it, and I’d first of all like to welcome my guest, Kurt Glazemakers of Cyxtera. Kurt, welcome to DevOps Chat.

    Kurt Glazemakers: Hey, Alan. Hi.

    Shimel: Thanks for being here, Kurt. So Kurt, let’s start off with this first. What’s your title over at Cyxtera?

    Glazemakers: I’m the CTO for our Secure Access product families, so I’m basically managing the whole development themes and the product for our Secure Access product family in Cyxtera.

    Shimel: Excellent. And among the Secure Access products that Cyxtera is offering is something called AppGate.

    Glazemakers: Yes, that’s correct. 

    Shimel: Give our audience a little background. What’s AppGate about?

    Glazemakers: So AppGate is a tool that’s based on some of the fundamental principles of zero trust, to provide clients, wherever they are – in the office, in the airport, maybe in a Starbucks – secure access to their core applications and in such a way that the applications are securely accessed wherever you are and from whatever device you have. That’s basically in a nutshell what it does. It _____ a wide network _____.

    Shimel: Got it. And Kurt, you know, bigger picture, Cyxtera, give me if you can, our listeners a little background there.

    Glazemakers: Well yeah, sure. So Cyxtera is pretty new in the market. We’ve existed exactly one year and 25 days today, so it’s pretty new. And it’s an acquisition of 57 data centers that we acquired from CenturyLink, and where we added security software in order to provide secure _____ and hosting _____ _____ .

    Shimel: Excellent, excellent. So is AppGate – I imagine it’s not offered just to your datacenter customers, or is it?

    Glazemakers: No, actually AppGate came from one of those software acquisition teams, so we actually are widespread. We have widespread customers all over the world, actually. But most of the data center customers have a need for it, because they need to access their own data center _____ _____ requirements. Maybe they have access needs in the cloud, like the _____ clouds of this world, like the 80S or the ____ of this world. And with AppGate you can actually accommodate all of them with one solution. And with our footprint in the data center we can even offer it as a secure access service to our customers. So that’s a combination of the software and the data center footprint, which makes it very interesting from that perspective.

    Shimel: Got it. So we’ve got the groundwork laid, Kurt. Let us now jump into what you and I really want to talk about, and that is that, you know, Cyxtera and the AppGate team have been on their own DevOps journey, their own DevOps transformation in how you’re actually developing and continue to develop AppGate as a product. And what’s really kind of unique about it – it’s like one of those Russian dolls where it’s a doll within a doll within a doll – is you’re using DevOps to help develop a product that helps DevOps. Right? Other DevOps _____.

    Glazemakers: Yes, that’s actually correct.

    Shimel: Tell us.

    Glazemakers: Yeah, so what AppGate basically does, it provides secure access to applications, but the applications are dynamically discovered and added to the network, which is a real DevOps case, right? If you spin up an environment and you want to connect to that environment, even if it’s only lost for like a few minutes, AppGate is able to detect that and basically provide access in the moment that the environment is live. And when it’s gone, all of the access rules are gone as well. So it is nakedly a DevOps-driven security technology, which helps a lot of or actually most of our customers already in a public cloud or DevOps style of company, as a majority. Also we have enterprise customers, but this has actually been very well adopted in the DevOps _____. Yeah, so it definitely is a doll in a doll from that perspective, for sure.

    If I go back to where we started, I started these tools about four years ago. And the reason why DevOps for us was so important is, first of all, it’s a network security product, which is very, very complicated in testing, because it requires a lot of security skills, a lot of networking skills and also software testing skills, which makes it very hard to basically perform the amount of testing in _____ hours, to give quick feedback to the user side or to the developer, in this case. So one of the things we’ve done in the very first place is we really spend a lot of time on creating our own tools, and that actually took even more than a year or a year and a half, to transform what, at the time when I entered the organization, was a more traditional way of developing with a developing process, a QA process, a delivery process. And that process was too slow and didn’t get or give the right outcomes.

    So the first thing we’ve done – we spent about one and a half years on only developing the automations and the DevOps _____ _____ case. So yes, that’s where we spent a lot of time and actually that’s also helped us in gaining a lot of efficiency in the dev team after _____ _____ _____ in this case.

    Shimel: Excellent. So Kurt, you know, we’ve spoken to several – more than several. We’ve spoken to a lot of organizations that have kind of undergone their DevOps transformation. If you can, share with our audience, how did this come about? Was it top-down, bottom-up, middle-out? You know, whose bright idea was it to do DevOps here?

    Glazemakers: Yeah, okay. I think you need actually a little bit of both, right? So when I entered the company, I had some experience in the past and I really wanted to bring it to the same level, because first of all, the QA profiles are very hard to find and they don’t have the same throughput than if you do it in a proper DevOps way. So I definitely wanted to put guidelines in here, but you cannot do it if you don’t have buy-in from your own devs right now. And these devs were immediately onboard and we started actually as a _____. So basically I would say this is a top-down and a bottom-up approach at the same time.

    But that definitely brings challenges, because if you go from a traditional way to a new way, it means that certain people probably will not be a fit in the reorganization, right? So if you have too many people that have never been a coder, that actually brings challenges on their skillsets. So that was not the easiest way to progress in the organization, but once everyone saw the benefits, I think we really shifted from a traditional-driven organization to a full DevOps and really a _____ _____ _____ organization. We did it in that year and a half I was talking about. So yes, that’s the guideline. But you need buy-in from both your developers as well as the management team, in this case.

    Shimel: Excellent. And now, Kurt, since you’ve moved to a DevOps sort of framework here, have you guys done any sort of ROI or any sort of analysis as to what – I mean, because one of the things that we always see with DevOps is it just feels that it’s better, right? We’re doing it faster; quality seems a little higher. But have you actually done any benchmarks or metrics that really get to that?

    Glazemakers: Yeah, that’s actually a very good question. Actually it’s always hard to measure exact benchmarks, but if you look from an overall perspective, before, we were literally doing maybe one release every year, and that shifted almost to a multi-year release when this was adopted, which is a huge difference in this case. And the way we release is typically we have some quarterly release that contains all of the new features and then a monthly release which contains smaller fixes and patches. But what the biggest outcome was for us in this case is, by having a quarterly release and these smaller releases, it’s very easy to follow up with your customers on requirements.

    Especially in the beginning when AppGate was the complete new concept. So it’s _____ _____ _____, and you need to convince customers. At that very, very early stage, “Yes, it’s great, but I need this feature or whatever before I can work.” And if you can actually deliver that by the end of the quarter and even prove to the customer it actually works, that definitely helps driving sales and getting the numbers in, in the quarter. So I would say from that perspective it’s not only about releases but the fact that we were so dynamic and were able to convince customers. To inject a last missing feature before they could sign a deal is probably the most visible item that even _____ _____ _____ by sales or management. Because you are actually fulfilling needs from a customer at a much faster pace in each case, which results in better financial results and more happy customers as well 

    Shimel: Excellent. Excellent. So what’s been the feedback? You know, as you said, it makes for happier customers and everything else, but let’s concentrate on your own internal development team. What’s the feedback been from them?

    Glazemakers: In the beginning, a little bit skeptical, because you need to do all this move and the work and also you don’t involve the right group files. The nice thing is, what happened is, when they start to see the power of a properly-done DevOps file – and actually we have a little bit of a benefit with our product, because we’re not only leveraging DevOps as the _____ _____, making sure that we have all of these automated tests _____ _____ feedback, but we’re also using always our latest code base to basically upload the codes and to work with it. So even the code right now, I’m actually using the latest version at this moment, through a secure _____, to basically provide _____ _____. So you see that you immediately get feedback from that perspective.

    So the first thing that we really saw beneficial for the devs is that they get very, very quickly feedback, to see how the software performs. But secondly, also when we were _____ _____ the organization – you get a lot of new talent in and the new talent is typically a little bit shyer, because if they commit something and it breaks a process, then you get – that’s not how you want to start in a new company. And with this DevOps style, where people cannot commit code before it went to the test _____ and before it can be merged and all of those things, you have first of all a very strong development process, which is not followed by developers, because they hardly feel there’s any process. And so it gives the developer at the same time a lot of freedom and a lot of trust in whatever code they produce.

    And those three elements are incredibly key to raising the amount of efficiency, because people are not blocked because someone has entered the wrong code that actually breaks the builds. We have a lot more freedom to basically optimize or _____ _____ certain codes in the products. And last but not least, also from a security perspective, you need very, very tough certification sometimes, even if you are producing for government agencies and those kind of things. And that automation also provides a lot of feedback there, positive feedback, for the certification process, because everything is automated and enforced by the DevOps system as well in this case. 

    Shimel: Mm-hmm, excellent. So Kurt, I told you the time goes so fast. We’re almost out of time. But I wanted to talk a little bit about the other side of the house, which is, how are customers using this to help their own DevOps initiatives and their own DevOps development and deployments?

    Glazemakers: Yeah. Yeah, that’s actually a very good question. Yeah, what you have with DevOps environments is, when you’re deploying in DevOps environments, you basically always typically want to deploy and actually forget about it, unless there is an issue when you want to go in. And this is typically administrative access for the development outside the system. And in a real production environment, in a DevOps environment, you really, really want to have strict, strict controls of that. And we have a lot of customers, for example, that maybe _____ _____ _____ that actually have this kind of discipline. And what we were able to provide was when they – even when it’s their own dev environment and they test, or if it’s a production environment, we can actually enforce different layers of access in this case. Maybe for the public environments you need two-factor application and a company-approved device in this case, or a security device that has all of the endpoint protection software and stuff like that running. And maybe for the DevOps environment itself, where all they’re doing is pre-tests, we might be a little bit less restricted. So normally like a normal device, “Okay, it’s just _____ _____,” and you’re able to access without – with just login and password, as an example.

    The nice thing is, what our software does, it can actually provide both of these things at the same time. And also, when the environment is being sped up, the metadata that you provide by creating the environment can be used as the security mechanism. And this is really where we bring a lot of value for customers. Because if you have a DevOps environment that changes all of the time – changes IP addresses, changes operating systems and all of those things – even if they’re lost for maybe 10 or 15 minutes, we can automatically detect those and be able to provide _____ _____ if needed. If they have an open ticket or whatever, we can all combine those elements. And once that is received, we also have a proper _____, the records for which developer has access with the system, even if the system doesn’t exist anymore.

    And that has been a great value for DevOps, especially in the financial world where DevOps becomes now _____ _____ _____ interesting. Financials are seeing the need that they need to develop at a higher pace, so they’re embracing DevOps. But at the same time they are very, very highly regulated, and that doesn’t change. And what we can do with our software is really provide the same or even sometimes better control of these regulations at the same time they keep their agility on the DevOps process _____ _____ _____.

    Shimel: Got it, got it. So Kurt, as I mentioned, time does go fast. We’re running out here. But just last question – what’s the future look like with this?

    Glazemakers: Well I have no idea what it will look like, but the way I see the adoption right now, the way I see the need for DevOps and actually the DevOps embraced in many companies these days, I’m pretty sure that the old way of securing clouds or virtual environments, using a primitive _____ defense or _____ _____, it’s too dynamic ______. There are too many hacks going around. And so from our approach, I would say this is definitely a completely new way of securing DevOps environments and, they’re also the first signs of _____ DevOps are on the horizon right now. And this is a fit. I think the first product that really takes into account whatever security _____ _____ _____ DevOps environments is immediately enforced on the network, all the way down to the user device. And that basically extends whatever you’re programming in your DevOps environments, to make sure it’s always secured down to the device of the user itself.

    And I think that is going to be a huge driver of better security, but also in a much more dynamic security type of approach, which – DevOps has done a lot of great work on deployment and infrastructure. The network and security elements didn’t go as fast, and I think this is probably one of the next new waves that will drive that and maybe be even more secure than traditional environments using the dynamic approach _____ _____

    Shimel: Okay. Excellent. Well, that was a great kind of insight, Kurt. I appreciate it. We’ll be looking – you know, a year? What did you say, a year and 30 days or so?

    Glazemakers: Yes, that’s exactly – a year and 25 days. That’s how old Cyxtera is right now.

    Shimel: Well, continued success and we’ll be watching Cyxtera’s growth. Thanks for being our guest today on DevOps Chat, and we hope to have you back on again soon.

    Glazemakers: Thank you very much as well, and have a great day. 

    Shimel: All right, Kurt Glazemakers, CTO for Secure Access for Cyxtera joining us today. This is Alan Shimel, and you’ve just listened to another DevOps Chat. Have a great day.

    — Alan Shimel

  • DevSecOps: Embedding a Security Practice into your DevOps Approach

    DevSecOps: Embedding a Security Practice into your DevOps Approach

    It’s a no-brainer that the element of security cannot be compromised even to the smallest of extents in today’s competitive, fast-paced, modern technology-driven IT infrastructure. However, to keep up with the rapid developments of other processes in this agile world, security is often given relatively less importance and in some cases, even left behind. As the term suggests, DevSecOps is primarily concerned with the incorporation of security in the DevOps pipeline.

    The intended primary function of DevSecOps is to help overcome the aforementioned barrier by extending the conventional framework of DevOps and inculcating security testing by means of various security tools. This article attempts to explore the significance, characteristics, benefits and challenges involved in DevSecOps implementation and practice.

    Why DevSecOps Matters

    Since the rate of cybercrime over the past few years has been increasing at a significantly high rate, the need for adoption and implementation of DevSecOps is also intensifying. An analytical study from Cybersecurity Ventures predicts that the damages incurred from cybercrime will be as high as $6 trillion annually by the year 2021, double the $3 trillion in 2015. As the benefits reaped from implementation are linked directly to the reduction in cyberattacks, DevSecOps is becoming the center of attention of IT decision-makers.

    Breaking Down DevSecOps

    The following factors constitute the core of the DevSecOps approach and are the key to a successful implementation:

    Automation

    While the concept of DevOps revolves around automating the build, test and deployment sections, DevSecOps additionally focuses on automating security. Automation is crucial as the security—besides being able to be scrupulous and comprehensive—also has to catch up with the much faster release cycles driven by DevOps. The target of DevSecOps is automating all of the security controls, thus eliminating the need for manual interference.

    People, Process and Technology

    The trio of people, process and technology is the pillar and it directly influences the extent of success of any DevSecOps approach and practice. The People—considered as the weakest link of the three—are the security specialists and integration of the security team with the development team. Appointing “security champions” who form a cross-functional team to work on the application security, is a key element of the People practice. The Process involves standardizing the workflow, documentation and execution of the same to make sure that the security is transparent with other processes in the workflow. The Technology refers to the various facets deployed in DevSecOps such as the automated vulnerability management, automated compliance scan, etc., whose applications are directly involved in the implementation.

    Different Tools for Different Functions

    There are a number of security tools that specialize in various aspects of the DevSecOps approach, including testing, secrets management, attack modeling and red team. Selecting the right tool for the right function is paramount and it is not always easy since many of them are still in the emerging phase.

    With DevSecOps, You Get …

    Enhanced overall security: The overall security of the infrastructure is strengthened by identifying and reducing vulnerabilities as and when they occur. In case some minor breaches happen, the rate at which the recovery happens is also escalated.

    Total Cost Reduction: Unlike the conventional approach, in DevSecOps the security issues are identified and dealt with in the development phase itself. Consequently, this leads to reduced overall costs incurred in the development and security of applications.

    Accelerated delivery speed: The implementation of DevSecOps consistently strives to detect and eliminate the security bottlenecks at various stages of development. This, in turn, increases the speed at which the product is delivered.

    Besides the above-mentioned benefits, DevSecOps also nurtures an environment of transparency and helps in increasing the customer value.

    But, Implemention is not a Piece of Cake

    Comprehensibly, there are many challenges that lie ahead before DevSecOps implementation. The availability of sufficiently skilled cybersecurity professionals is one of them. This is because the extent of expertise needed in cybersecurity is underrated when compared to other business units. Unlike the traditional environment, a DevSecOps methodology means that the various internal teams of the business unit such as the development and security teams need to work in unison, which might not always go smoothly. The fact that building secure code is time-consuming can frustrate developers, as it hampers their speed of delivery. Many mid- and low-level organizations are skeptical about security as, economically, it is viewed as more of a liability rather than an asset.

    In my next article, I will be applying a templated approach to shortlist tools that would be suitable for your organizational needs. For illustration, a series of webinars that cover the various aspects of implementation of DevOps can be found here.

    According to the WhiteHat Security Application Statistics Report, “The average customer takes 174 days to fix a vulnerability found when using dynamic analysis in production. However, those who have implemented DevSecOps do it in just 92 days. If we look at vulnerabilities found in development using static analysis, an average company takes 113 days, while the DevSecOps companies take just 51 days.” It is evident that, in the long run, the benefits reaped from DevSecOps outweigh the challenges. A successful approach drastically reduces the chances of succumbing to cybercrimes while being agile and revolving around the mindset, “Everyone is responsible for security.”

    — Kavin Elango