Tag: security

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

July 17, 2018

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

July 16, 2018
Connectivity as Code: Making Network Security DevOps-Friendly
DevOps is all about agility, with fast, short delivery cycles and automation for software development and applications. Enabled by recently introduced technologies such as virtualization, cloud and software-defined networking (SDN), spinning up new servers, provisioning storage in a public or private cloud or even launching whole environments can take just minutes or even seconds. But if that new application, service or environment needs a change in network connectivity or firewall rules to enable it to work, then the pace of delivery can often slow to a crawl.

Unlike the typical DevOps scenario, in which developers create a CI/CD pipeline that includes running build processes and tests and delivering the new application completely automatically, provisioning new network connectivity usually involves a slow, laborious process. The application developer needs to manually open a change request and then wait for approvals and implementation of the new connectivity flow before proceeding with the DevOps flow.

The Application Development Security Disconnect

As part of this, the developer is usually required to provide information about firewalls, zones, subnets and other information related to the underlying network infrastructure in these change requests—information that is not always known or clear to the application developer. On the other hand, the application requirements and context are not always understood by the network security team assigned to implement the changes. This can result in back-and-forth communication between the developer and network security, making the entire process extremely long, error-prone, inefficient and frustrating to both teams.

The challenge here is building in the necessary checks and balances to ensure that DevOps processes are not rapidly introducing security problems, while equally ensuring that security is not stepping on the brakes and slowing down the organization’s agility. So, how can this be achieved?

The Solution: Connectivity as Code

The answer is connectivity as code, a methodology that supports not only automation and agility in the application delivery process but also bridges the gap between application developers and network security teams on an ongoing basis, even after the application is deployed into production.

Connectivity as code creates an abstraction layer that translates between the two worlds, giving application developers more control over their applications while helping network security understand the business impact of their day-to-day tasks, and thus ensuring business continuity.

Establishing Connectivity Requirements

In the first stage of this approach, the application developer describes the application connectivity requirements in a simple machine-readable text file, listing all the logical flows that represent these requirements, including those for the different application environments (e.g. test, development, production, etc.). It is presented as a list of abstract flows that typically include the source (who initiates the connection), destination (who accepts the connection), service and additional information.

There is no need to know where the servers are located or what the underlying network topology is—such as whether there is a firewall between them or cloud security controls—or even their IP addresses or subnets. Furthermore, there also is no need to know whether connectivity is already available, because it’s also required by other applications.

The Connectivity Phase

Once this list is created, a new phase in the DevOps process, the connectivity phase, will automatically take care of things with no further involvement required from the application developer. The connectivity phase is where the actual connectivity provisioning and validation happens, leveraging a network security policy management (NSPM) solution to automate the network connectivity provisioning as part of the DevOps process just like any other configuration or provisioning step in the DevOps pipeline.

The NSPM solution will read the file before automatically checking whether the connectivity requirements have changed. If no changes were made, the solution will verify that the required connectivity remains in place, and that the application will work correctly. This provides the application developer with the assurance that the necessary connectivity is in place and connectivity-related failures are not anticipated when moving into production.

Automating Connectivity Changes

If the connectivity requirements have changed, the NSPM solution will use the connectivity file to provision the required connectivity while retaining it for future reference, so that the application’s connectivity remains intact in the event of future network architecture changes or application or server migrations.

If one or more of the required flows is currently blocked, a security policy change request process is triggered. Through this process a NSPM will verify that the new flows comply with the organization’s preapproved security policy, as well as security best practices and industry regulations, and will then design and implement the required changes directly on the different security devices on the network, automatically and within minutes.

If, however, a change request is non-compliant, it will be escalated for approval and, once approved, it will be implemented automatically, thereby saving the developer the need to manually open an out-of-band change request.

Furthermore, whenever a new version of the application is developed, this list of connectivity requirements is updated by the developer and the connectivity phase will ensure that the new flows are provisioned. With the connectivity phase completed, the DevOps process can securely proceed onto the next phase.

The Benefits of Connectivity as Code

Introducing the connectivity-as-code methodology into the DevOps process achieves a range of benefits. These include:
- Seamless management of network connectivity: This makes DevOps process far faster and more agile, and enables problem-free application delivery, rather than as an external out-of-band issue that requires separate—and manual—handling.
- Continuous compliance and auditability: Throughout the application delivery process organizations will remain fully compliant with all relevant guidelines, while all changes are fully logged for auditing purposes.
- Business continuity: Application connectivity requirements are clearly documented and up to date, ensuring minimal disruption to the business even during network, infrastructure or architecture changes.
Ultimately, connectivity as code bridges the gap between application developers and network security throughout the entire application life cycle, from planning and development through to deployment, production and decommissioning. It ensures both developer and security teams get what they want: Dev teams don’t have to worry about security slowing them down, and security teams know that risk and compliance checks have been built in to the continuous delivery process, complete with a full audit trail of changes. By weaving network connectivity into the DevOps process, organizations can ensure fast delivery without any compromise in security or compliance.

— Anner Kushnir
July 13, 2018
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

June 27, 2018
Integrating Blockchain and DevOps

Blockchain is one of today’s hottest technology buzzwords. And at the same time, the concept of DevOps has achieved acceptance and is gaining momentum. Blockchain and DevOps already offer a number of benefits individually. Together, they can provide significant tactical and strategic advantages. However, some challenges must be overcome simply to adopt blockchain, as well as to successfully merge blockchain and DevOps.

What is Blockchain?

Let’s start with an overview of blockchain. Many people mistakenly conflate cryptocurrency and blockchain, because many of the key features of cryptocurrency are a function of blockchain. But blockchain is a separate and unique concept that has applications and benefits far beyond cryptocurrency.

Blockchain is a distributed account ledger, the use of which enables data to be processed and stored securely. Blockchain relies on three core concepts—peer-to-peer networks, public-key cryptography and distributed consensus that is based on the resolution of a random mathematical challenge. Reliance on these three concepts allows blockchain transactions to be secure and relatively anonymous. Every transaction is recorded in the ledger as a data block that is appended to the end of the chain of previous transactions. No group or individual owns or controls the ledger, and all parties can view the chain of transactions, ensuring transparency and integrity.

A number of key features make blockchain attractive. Data is validated across all participating nodes, which eliminates the need to reconcile transactions. The use of distributed consensus provides a high degree of confidence, but transactions in the chain also can be verified easily. Blockchains are immutable—new data can be appended, but blocks of data already in the chain cannot be modified or removed. Finally, blockchain reduces costs and improves the efficiency of processing transactions and storing data due to its decentralized architecture.

The challenge facing organizations wanting to adopt blockchain, however, is how to incorporate it seamlessly with DevOps development processes and culture.

DevOps for Blockchain Development

Organizations need to address challenges in three major areas to take advantage of blockchain: culture, process and tools.

On the culture front, the success of blockchain depends on support at the executive level as well as adequate budget and resources for proper implementation. If you can’t find champions within the organization to drive the blockchain cause, your project is doomed before it starts.

Whether you’re building a blockchain within a single company or a blockchain network that includes nodes outside your organization, obtaining widespread agreement on the technology and blockchain processes can be an issue. The absence of widespread industry adoption or any sort of standardized tools or processes adds complexity.

Finding the right talent can also be a problem—and once you find it, you may have to pay a premium to obtain it. According to a recent article in TechCrunch, “Blockchain-related jobs are the second-fastest growing in today’s labor market; there are now 14 job openings for every one blockchain developer.”

From a process perspective, blockchain is an emerging concept that lacks mature management principles or design standards. The process framework, and the different roles involved, are still unclear. Most organizations lack expertise concerning the blockchain application stack and environment; in addition, the metrics that should be monitored to measure efficiency and performance are not yet well-defined.

The absence of development tools is another major hurdle for blockchain. The developer tools currently available for the blockchain ecosystem are unreliable. The blockchain ecosystem still needs an integrated development environment with good linters and plug-ins, a build tool and compiler, a deployment tool, documentation, testing frameworks, debugging tools, logging tools, security auditing and analytics. While some versions of these tools exist, they are not yet adequate to meet the needs of blockchain developers.

It is also important to understand that, although many blockchain implementations are based on open source technology, blockchain isn’t free. Keeping track of transactions requires hardware, networking bandwidth, electricity and processing power. Because a blockchain ledger is distributed, transactions aren’t just processed once—they are processed on every node in the blockchain network. As a trusted network grows, the associated costs skyrocket. These expenses can be a barrier that prevents smaller organizations from experimenting with the technology.

Integrating Security into DevOps

If you are thinking about implementing blockchain, some of the core principles of DevOps—specifically DevSecOps—come in handy. DevOps is built on the concept of breaking down silos within an organization and enabling each team and individual to take responsibility for the project as a whole, rather than separating tasks by role.

To implement blockchain successfully, you need a system that rewards innovation and supports teams of individuals who work together to address any issues. Integrating DevOps and security fosters stronger application security throughout the software development life cycle and helps with blockchain development efforts as well.

The shift-left philosophy and the push for automation are DevOps principles that also will serve you well with blockchain. Integrating security earlier in the life cycle—shifting left—and incorporating automated security testing and security bug tracking are essential. The blockchain network needs to be tested for performance and latency, which will vary depending on the size of the network, the expected transaction size, the consensus protocol used and the associated required latencies. It is also important to determine whether the integrity of the network and the shared blockchain ledger is maintained while testing throughput.

To maximize efficiency and productivity, put processes in place that allow you to consistently monitor and adjust, based on feedback. Track individual and overall security vulnerabilities, the amount of time it takes to detect them, the amount of time it takes to remediate them, and other factors relevant to application security. These metrics should be visible to every individual so that each can understand and take ownership of the appropriate elements.

Blockchain and DevOps

Blockchain technology is poised to change the way business is conducted today due to its promises such as of secure, immutable, peer-to-peer decentralized trust networks with distributed consensus, shared account ledgers and smart contracts.

These same advantages, however, introduce a host of additional considerations to blockchain-based applications and make for greater testing challenges. Not only is the change in technology significant, significant changes are also necessary from a business process standpoint. While blockchain applications will have to go through standard testing and validation, including functional testing, integration testing, security testing and performance testing, they also will require additional specialized testing for smart contracts and peer/node testing.

DevOps practices can provide great value to organizations under pressure to become more customer-centric and innovation-focused. The efficiency, quality and consistency that adopting DevOps provides is exactly what is required for traditional organizations looking to embrace the leading-edge technology known as blockchain.

— Tej Aulakh

June 25, 2018
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

June 14, 2018
Serverless: What You Need to Know

There are clear benefits to serverless architecture, with many enterprises already making or planning to make this change. Like any paradigm shift however, the move to serverless carries both benefits and risks. Here’s what you need to know.

AWS pioneered the serverless space with its release of AWS Lambda back in 2014, with the other major cloud providers following: Azure Functions as a service, Google Functions and IBM Cloud Functions (Apache Openwhisk). Later entrants in this space took the form of container-based, fully-managed serverless frameworks such as Kubeless.

The Good, the Bad and the Use Cases

Some of the most common serverless use cases today include building batch processing like image compression, cloud job automation, serving IoT devices from edge to the cloud and building single page applications (SPA).

On one hand, cloud-hosted serverless functions eliminate the overhead associated with managing actual infrastructure and introduce significant operational cost savings through efficient utilization of the underlying infrastructure. This allows developers to develop in their own comfort zone, using their language of choice: Python, JavaScript and, depending on the platform, even Go, Java, C#, PHP or others.

On the other hand, delegating the infrastructure control to the provider means that serverless introduces new set of operational blind spots and observability challenges. It also complicates the placement and management of deep security controls, when compared to container, virtual machine (VM) or even bare-metal workloads.

Serverless is Not the Answer for Everything

Whether building new applications or migrating existing ones, serverless runtimes have significant restrictions. Cloud-hosted functions-as-a-service restrict the runtime duration of a function, require a “warm-up” time for function invocation and don’t guarantee local state preservation across function invocations. This means that application logic that is purely time-bounded, involves short functional transformation of input into output and can handle a slow starting time would fit the serverless paradigm perfectly.

Migrating state-oriented applications or stateful microservices into serverless functions is a different story. This will typically make use of a database—either managed or as a service—or make use of an application cache such as Redis or object store such as S3 to store state across requests.

While cloud-hosted serverless removes the burden of patching and maintaining infrastructure, the ephemeral nature of functions makes it extremely challenging when it comes to establishing perimeters and controls around sensitive data in flight and at rest.

Build, Ship and Run Serverless

Serverless, as young as it may be, is extremely promising. Adoption choices should be balanced around platform maturity for developers, testing, operations and what security and regulations require.

If we take as an example what Docker did for container packaging, with its Container Image format, this is exactly what functions and serverless need: a common language for packaging. A common tool for building, shipping, running, operating and securing function-based workloads would serve as common ground for the variety of platforms already out there.

From a security perspective, unification around secret consumption, service-to-service authentication and authorization between first and third parties, function workflows and access whitelisting, observability, security network monitoring, access policies to the network and access policies to data—all these would lower the friction of adoption.

The Cloud Native Computing Foundation recently released version 0.1 of Cloud Events, the communication message format for function and event triggering. This emphasizes how far serverless is yet from maturity and cohesive standards.

From a security perspective, Type A serverless workload protection systems must be able to inspect the serverless workload runtime. Type B workload protection systems are limited to what the serverless platform provider APIs make available for out-of-band data-oriented security analysis.

Cloud-hosted functions makes Type A protection challenging to achieve, whereas fully managed serverless frameworks (for example, Kubeless), enables enterprises to adopt serverless and open the door for new developer experience. These also accelerate innovation velocity and, with security tools designed for microservices and modern virtualization technologies, can maintain full visibility and runtime control over network and data.

Securing Functions as a Service: A New Arsenal of Security Tools

Functions, just like any other web-based microservice implemented using containers, VMs or bare-metal server, are not free from the well-known top 10 OWASP web application vulnerability list.

Functions, however, strongly rely on non-web, event-based communications and event-based networking channels. These, on public cloud providers, prevent inserting security controls to detect exploitation attempts or data exfiltration and enforce well-defined workload policies. This requires new arsenal of security tools that understand microservices, scale horizontally and coexist with the existing security operations and security stack.

The ephemeral nature of functions-based workloads makes them more difficult to exploit, and it is definitely harder to persist a threat. Yet third-party code vulnerability or open source components gone bad can result in sensitive data flowing into the wrong hands, landing in a misconfigured object store.

As serverless requires persistent data storage in external services, a scenario in which circumventing a running function to leak secrets makes that sensitive data one hop away from an attacker is not unrealistic.

Controlling it all together: What private information can be processed, what sensitive data is in flight and through which event grid channels it’s being received and sent, along with how functions are invoked by API gateways and which API calls which functions make to internal and external services. This is where risk, regulation and modernization collide.

Bottom Line

Despite significant adoption and constantly growing interest, serverless is still in its infancy. When it comes to standards, operations, testing and orchestration tooling, workflows and security, a flood of water must yet pass under the innovation bridge of cloud providers, with AWS Lambda leading the adoption curve, Azure FaaS making giant innovative leaps forward and community-driven frameworks built on top of Kubernetes.

Innovation aside, serverless creates huge operational and security blind spots. Understanding those risks and having proper introspection and inspection capabilities is what should dictate the adoption and the choice of the platform.

— Gadi Naor

June 14, 2018
Making DevOps a Reality – Bringing in Security: Top 4 Topics

I caught up with Maria Loughlin, vice president of engineering at CA Veracode; Chris Eng, vice president of research at CA Veracode; and Alan Shimel, CEO of devopsy.kinsta.cloud, to talk more about their recent panel webinar on bringing in security to make DevOps a reality. It was enlightening to hear their perspectives on how companies can build security into its culture so that it permeates the development process. Many enterprises have realized that with the continuing popularity of DevOps comes the possibility of creating an environment that allows software vulnerabilities. In truth, more teams are integrating security testing into their development processes.

This informative session is available here on demand and worth a listen. But I’d like to share the top four topics from their discussion:

New Mindset and New Speed

As dev moves to DevOps, traditional approaches to security aren’t fast enough. Both the challenges of scale and the lack of expertise on the teams need to be addressed.

Faster, Cheaper, Better

DevOps makes integrating security easier in a few ways. First, engineers understand they need to take more operational responsibility, and that includes security; and secondly, DevOps emphasizes the investment in automation and continuous delivery of small batch sizes. As much as we automate security, it becomes less costly, transparent and readily adopted.

People Aspect in DevOps: Just as Important as the Technology

Teams do need to interact differently in a DevOps environment. The partnership must be real and show empathy, respect and flexibility. Expect the security teams to be reasonable and take a risk-based contextual approach; not everything is critical.

Most importantly, that interaction must start at the top, just as it does with Maria and Chris, with a shared goal of success and accountability.

Their Parting Advice

Make the secure way the easy way. Implementing secure building blocks not only saves time but reduces your risk. Look for opportunities to simplify and automate to optimize your investments.

Sometimes, it is best to start small. Your investments will grow over time with nurturing.

Your people are your most valuable assets. Be sure to monitor and mentor the skills gap on your team because if team members aren’t knowledgeable they can’t be held accountable. Make sure that executive sponsorship is involved and visible.

There was so much more. Luckily, you can still watch the entire webinar. It’s available here.

— BeckyArenson

June 12, 2018
There’s No Such Thing as DevSecOps
Should DevSecOps be categorized separate from DevOps?

After years of debate, few doubts remain about the viability of the public cloud for enterprise workloads. Enterprises are shifting to cloud-first and cloud-only strategies, looking to take advantage of all the good the public cloud has to offer. For applications built and deployed in the public cloud, it is all about automation. The cloud enables you to be elastic, reduce costs and deliver products faster. To achieve these goals, you need to automate your processes—building, testing and deployment.

Security Challenges of DevOps

This need for faster innovation led to the rise of DevOps, a set of practices and tools that result in tighter collaboration between development and operations. In the past, controlling the deployment processes was the responsibility of dedicated teams that wrote scripts. However, with DevOps, development and deployment merge. Software engineers must do more than write their infrastructure and business logic code; they also need to write the automation that surrounds it and take responsible for deploying it through the different stages until production.

However, even as development and operations come closer together, security has remained a function apart. While DevOps workflows are heavily automated, security checks for application and infrastructure code often are manual. DevOps and security teams are measured differently—delivery versus protection—and often are at odds with each other. The siloed approaches to security hardening that worked in the past are incompatible with the holistic, iterative software development and deployment model of DevOps.

For a developer, adding the responsibilities associated with DevOps is not complicated, but securing the environment is a different level of challenge that requires mindset shifts in multiple areas:
1. Knowledge: Software engineers are great at writing business logic. They write efficient code and develop highly available environments that can handle millions of concurrent users. However, the vast majority of developers don’t know about the latest CVEs or the proper configurations of SSL/TLS in the load balancer.
2. Pace: Successful development organizations move fast, frequently adopting new development trends and frameworks. Public cloud vendors release new features every week, and it can be difficult to follow and keep up, as engineering is usually measured by the ability to deliver and the quality of output. DevOps enables rapid release cycles, and the security must not hold them back.
3. Scale: Modern applications make the transition to work with microservices. When each development team owns its cloud environment (and sometimes multiple environments), the security teams suddenly find themselves dealing with huge distributed deployments. They can’t manually configure security when new features are released a few times a day in different environments.
4. Heterogeneity: Multi-cloud deployments are another emerging trend. New product teams are often given a free hand choosing their tools and infrastructure, and they may pick a new cloud vendor. While security teams have a voice in this decision, they do not have the last word. It may have taken the security team years to learn to deal with the existing cloud solution, and suddenly the organizational policy needs to be applied across different infrastructures.
5. Consistency: Enforcing organizational policy across different development teams is challenging. Each team has its own style, environment and development frameworks, meaning it’s never easy to ensure the security is applied uniformly.
However you choose to address all these challenges, one thing must be clear: Your DevOps cycle is not complete without handling the security.

Choosing a Security Solution

Clearly, you can’t deploy services without properly securing them—you don’t want anyone to hack into your systems and steal your (and your customers’) information. Since cloud environments are dynamic and deployments tend to span across dozens of accounts, manual steps are not an option. Automation is necessary. Whether you acquire an enterprise security solution, adopt an open source security project or write your own tools, you need to make sure that they are:
1. CI/CD ready: The solution can easily integrate into the continuous integration/continuous compliance pipeline. User-friendly APIs are required.
2. Scalable: Assessing hundreds of cloud environments requires the solution to be scalable and robust. When covering more cloud vendor capabilities, performance becomes critical and increasingly challenging.
3. Flexible: Each organization is different, and security needs can vary with each deployment. The baseline configuration of your security solution will never meet your requirements by 100 percent, so it’s important that you be able to adapt it to your needs.
4. Continuously updated: Cloud vendors add new features at a rapid pace, which also means new potential misconfigurations are generated all the time. Whatever solution you choose, it needs to match the cloud vendors’ speed and agility. Security solutions that are not being updated soon become useless.
5. Conveniently Reportable: Aggregated reporting is critical. Consuming the security findings in a convenient manner can assure that issues are properly mitigated.
6. Automatic remediation-capable: Many of the findings are easy to remediate automatically. Applying automatic remediation would enable the security team to focus on complicated tasks and reduce alert fatigue.
DevOps and DevSecOps Are (or Should Be) the Same Thing

Security is clearly an integral part of DevOps. DevSecOps is emerging to bring security and compliance management practices in line with the rest of DevOps. DevSecOps serves to call out the temporary chasm that exists between security and DevOps.

As security checks and controls get automated and integrated, DevOps and DevSecOps are converging to the same thing. Just like adjusting the mirrors and putting on the seat belt are part of standard procedure before pulling your car out of the driveway, assessing your security posture before releasing a new version of your product must become habit. To remain relevant, your security team must integrate into the CI/CD and make sure the newly created environments meet organizational policies.

— Offir Zigelman
June 7, 2018
Aqua Security Survey Finds Sharp Rise in DevSecOps

A new survey of 80 cybersecurity professionals that attended the recent RSA Conference 2018 event finds the number of organizations that have a formal or informal DevSecOps team in place has increased by several orders of magnitude year over year.

The survey, conducted by Aqua Security, finds 62 percent of respondents have a formal or informal DevSecOps team. That’s up from last year, during which a similar survey found only 13 percent of respondents had a DevSecOps team in place.

It’s still early days when it comes to implementing DevSecOps processes. But Andy Feit, vice president of go-to-market for Aqua Security, said the survey also makes it clear that these formal and informal DevSecOps teams have access to budget dollars. More than three-quarters of respondents (76 percent) said their application security budget has increased over the past five years. One-quarter (25 percent) reported the application security budget went up between 10 percent and 30 percent, and another 14 percent said budget dollars being allocated to application security increased by more than 40 percent.

Well over half of respondents (57 percent) said they have the human and financial resources in place to implement DevSecOps. A total of 70 percent of respondents said they believe their culture can embrace the change needed to fuse security and DevOps. Nearly half the respondents (47 percent) reported they are fairly or very mature in their implementation of DevSecOps, while another 39 percent ranked themselves as maturing.

The three most important elements of DevSecOps as ranked by respondents ranked applying security across the app life cycle (61 percent), automating application security controls (52 percent) and involving DevOps in security processes (43 percent).

The shift to DevSecOps is occurring in tandem with increased reliance on microservices that are based on containers. As that shift occurs, Feit said IT organizations are rethinking their approach to application security. In delivering applications as a series of microservices, it becomes critical to apply a more granular approach to securing those applications that developers can apply as they build applications. Cybersecurity professionals will then be able to focus more of their efforts on crafting the security polices that developers implement, he said.

It may take a while longer before cybersecurity professionals gain enough confidence in containers to deploy them on physical servers with relying on a hypervisor to provide isolation. But it’s also now only a matter of time before developers insist on deploying containers applications on bare-metal servers to attain the maximum amount of performance possible by eliminating all the overhead added by a virtual machine. As that shift occurs, IT organizations will need new tools to secure and manage containers running on bare-metal servers.

As the same time, it’s clear that securing all those containers will require new processes such as DevSecOps because instead of patching applications to remediate them, developers will more easily replace specific containers to add new functions. Less clear is whether the adoption of DevSecOps will be driven from the top down or more as a grassroots initiative driven by the mutual self-interest of developers and IT security professionals. Regardless of the approach, cybersecurity as it is known today will not only be much different, but also arguably better.

— Mike Vizard

June 6, 2018