devopsy.kinsta.cloud

Category: DevSecOps

DevSecOps: Can JIT PAM Bring Relief?

IT and cybersecurity leaders have come to agree that the purpose and intent of DevSecOps is to create a mindset that “everyone is responsible for security,” while also incorporating application and infrastructure security directly into the software development and delivery process. DevSecOps has proven to be a critical ideology for cybersecurity, yet is littered with false starts and failures. Many of those failures can be attributed to a basic misunderstanding, wherein IT management has come to use the terms DevSecOps and DevOps interchangeably, because of the false belief that security is already part of the DevOps process.

A recent CyberArk DevOps Survey polled respondents to determine if DevOps and security teams were integrated, less than half of the respondents said yes. What’s more, almost three-quarters said they had no privileged account security strategy for DevOps and some 99% failed to identify all of the different places privileged accounts or secrets could exist in a DevOps environment. The survey demonstrates that common and well-established security practices have not been adopted by DevOps teams. Clearly, DevOps and DevSecOps are not synonymous.

A clear vision of what DevSecOps should be about can lead to DevOps teams releasing vulnerable software and exposing enterprises to unnecessary risk—a problem that has been manifesting itself in the rush to embrace digital transformation and re-engineer legacy apps into cloud-based equivalents. Expediency combined with a lack of understanding increases risk, which should cause alarm.

For the most part, breaches occur because of a lack of privilege management, In other words, proper security practices dictate the who, how and when of access, along with the permissions associated with that access. It is a concept that has given birth to platforms that manage privileges, also known as privileged access management (PAM) solutions. For DevSecOps to succeed, the concept of privilege must be embraced. However there is more to security than just privilege management; namely, the context of privilege must be incorporated, such as the “why,” “when,” and “where” of access.

Simply put, administrators and managers often forget to revoke the rights of temporary workers, contractors and other non-employees when a project is complete. It’s an issue that plagues many DevOps teams that rely on freelancers to help move the processes forward. The lesson here is one of instituting better controls and policies, which ultimately can be adopted throughout the enterprise to bring better cybersecurity to fruition.

JIT PAM to the DevSecOps Rescue?

Better control over privileges has created a new acronym, JIT (just in time), that takes residence in front of the PAM acronym. The concept of JIT PAM, which is being promoted by security vendors such as Beyond Trust, is one of controlling access based upon a number of different policies that are further enhanced with behavioral data.

At the recent Beyond Trust partner summit, cybersecurity expert Derek Smith noted, “Privileged credentials exist everywhere and 100% of all advanced attacks rely on exploits of privileged credentials.” That’s a sobering thought for those in charge of cybersecurity and those who are part of the DevSecOps process. Smith said some of the best practices around PAM include, “Track and secure, govern and control, and record and audit,” exemplifying the need for a platform approach. For Beyond Trust, that means creating a platform that defines a new paradigm of trust, one that builds policy around the who,what,why,where,when of access.

The concept offers valuable lessons to DevSecOps team members, lessons that entail incorporating the proper security elements into the application and infrastructure layers of service delivery. For the short term, those capabilities may be beyond those in the DevOps arena, meaning that they may have to turn to third-party platforms to bring forth better security. On the plus side, JIT PAM can also be used to secure legacy applications, giving DevSecOps teams more breathing room to define and re-engineer those legacy applications as they transition to the cloud.

— Frank Ohlhorst

May 6, 2019
Guess Who’s Coming to JFrog swampUP?

The annual DevOps gathering and JFrog user conference, swampUP 2019, is going to be here before we know it. It’s happening June 17-19 in San Francisco, providing easy access for everyone (it’s just 30 minutes away from SFO airport).

What’s swampUP? For the thriving DevOps community, swampUP is the must-attend event where developers, engineers and business leaders from top companies and industries network and share best practices for software delivery success.

While conference promotions can certainly be full of fluffy cheerleading at times, one thing I’m especially excited about is this year’s swampUP guest keynote speaker, Dr. Nicole Forsgren.

Dr. Forsgren, described as “snarky” by Forbes—a label she readily owns, if you ask—is the co-founder of DevOps Research and Assessment (DORA), which was recently acquired by Google Cloud. DORA quantified customers’ unique needs and DevOps processes to deliver custom paths to DevOps growth.

Coming to swampUP as herself—not that she could come any other way, but not as a representative of Google—to talk about her unique research and the overall landscape. She’s planning on covering many of today’s hot topics, including DevSecOps, cloud and hybrid, tooling trends and DevOps culture in a special keynote aptly titled, “DevOps: It Only Works When You Do it Right.”

If you don’t know Forsgren or haven’t seen her speak, her style and unique perspective perfectly blend data and statistics with understanding of realities that companies face. A bit about her specifically: Forsgren is co-founder, CEO and chief scientist at DORA. She is best known for her work measuring the technology process and as the lead investigator on the largest DevOps studies to date. She has been a professor, sysadmin and performance engineer. Her work has been published in several peer-reviewed journals. Nicole earned her PhD in management information systems from the University of Arizona, and is a research affiliate at Clemson University and Florida International University.

Once attendees get knowledge laid on them from Forsgren, there are some intriguing sessions available in the recently released full swampUP agenda around Cloud Native DevOps, Enterprise DevOps, DevSecOps and even some really cool-looking stuff around IoT. While this may be a JFrog user conference, there are some heavy hitters involved that make this a holistic DevOps gathering, including Andy Glover of Netflix, Aaron Schlesinger of Microsoft, Jayne Groll of the DevOps Institute, Carl Quinn of Zoox, Seth Vargo of Google, Jessica Deen of Azure and John Willis of Botchagalupe, among many other powerhouse speakers.

Of course, you’ll also see the expected lineup of JFrog experts, staff and visionaries swampUP attendees have come to know, including JFrog co-founder and CEO Shlomi Ben Haim, co-founder and CTO Yoav Landman, co-founder and chief data scientist Fred Simon, CPO Dror Bereznitsky, VP of business development Kit Merker and many more. There will be a few special additions this year, including former CEO of recently acquired Shippable Avi Cavale and JFrog VP of technology Ido Green.

From hands-on training to inspiring keynotes and practical technical breakout sessions, swampUp is seen by alums as a premier opportunity to learn about DevOps, DevSecOps and cloud-native delivery. There’s also a full day of training and certifications for practitioners of all levels to take advantage of!

Click here to register and join JFrog and the DevOps community at swampUP 2019.

— Jens Eckels

April 26, 2019
The Challenge of Securing a Dynamic, Cloud-Based DevOps Environment

The tech landscape has fundamentally changed over the last decade. The steady migration from local data centers to cloud computing combined with the advent of DevOps and the rise of containers have taken what was a more or less contained and relatively stable environment and transformed it into a dynamic, constantly shifting ecosystem. At the same time, the volume of exploits and threats has risen exponentially. The challenge today is how to effectively secure and protect servers, applications and data when your network is a moving target.

It Starts and Ends With Visibility

It’s difficult enough to protect something. Imagine that I give you a bag filled with money and tell you to keep it safe. There are risks involved and there will be criminals that want to steal the bag of money, but you have a fair idea of the threats you face. You know about the bag. It is in your possession. You can put it in a closet with only one entrance, make sure the door is locked and deadbolted, and monitor access with cameras. Now, consider how you would protect bags of money if hundreds of them could materialize at any point in time, anywhere in the house.

If you don’t even know how many bags of money there are or where they’re located, how can you effectively protect them? The answer is simple: you can’t. That is essentially the situation IT teams face with dynamic, cloud-based DevOps environments.

On a traditional, legacy network, it was relatively simple to keep track of how many servers were running in the data center and the applications running on them. One of the primary benefits of cloud computing, however, introduces one of the primary challenges of security in the cloud: The ability to scale capacity on demand adds elements of chaos and complexity that make it more difficult to know what exactly is on the network in real-time.

As with the bags of money illustration above, though, comprehensive visibility is crucial for effective security. You can’t protect what you can’t see—or what you aren’t aware exists at all.

Achieving Visibility in a Dynamic Environment

Of course, getting comprehensive visibility is easier said than done. Many organizations have a hybrid and/or multi-cloud environment, with assets and data in local data centers and spread across different public and private cloud systems. You can install agents on some resources that will provide accurate information about the current state in real-time, but there are also many devices and services that can’t run an agent—requiring more diverse and creative approaches to gain visibility.

The reality is that no single telemetry source will suffice. It takes a combination of active scanning, passive scanning, cloud-based accounts, agents running on devices and container-aware security to ensure that all of the various networks—and the servers, applications and services running on them—can be monitored and inventoried in real-time.

Comprehensive Visibility Equals Consolidated Visibility

Having broad visibility is not the same as having comprehensive visibility. Putting the tools and technologies in place to achieve and maintain comprehensive visibility is essential, but you also need to have the means to consolidate that information and manage it from a single console or pane of glass.

You need all of the various sources of visibility data to be integrated into a single, comprehensive view so the entire ecosystem can be analyzed, monitored and maintained from one central view. Effective cybersecurity depends on visibility, and comprehensive, real-time visibility in a dynamic cloud environment requires a security platform with both the agility and scalability to keep pace and provide you with the information necessary to prioritize and address issues as they arise.

— Tony Bradley

April 24, 2019
CloudBees Acquires Electric Cloud to Advance Continuous Delivery

CloudBees announced it has acquired Electric Cloud as part of an effort to extend the reach of its DevOps portfolio further into the realm of continuous delivery and application release automation (ARA).

Announced at the CloudBees Days event in San Francisco, the deal follows CloudBees’ acquisition of Codeship, a provider of a cloud-based continuous integration/continuous development (CI/CD) platform, last year.

CloudBees CEO Sacha Labourey said both deals are part of an effort to start rolling up many of the smaller companies providing DevOps tools that have not been able to achieve the critical mass required to operate at scale. As organizations of all sizes realize how much they depend on software to differentiate their company from competitors, he said, they are looking for a single vendor that can address all their requirements end to end. At the time of the acquisition, which closed earlier this month, Electric Cloud had 110 employees.

Labourey added the acquisition of Electric Cloud is also notable because it extends the reach of the CloudBees Jenkins and Jenkins X CI/CD platforms to the realm of application delivery for both legacy applications and emerging modern applications based on cloud-native microservices architectures.

While application development teams have largely embraced continuous integration, getting IT organizations to successfully implement continuous delivery has proven more challenging. The next phase of DevOps, Labourey said, will need to focus on applying machine learning algorithms to automatically discover the environment in which an application is to be deployed. Armed with those insights, it should be much easier for organizations to continuously deploy and update applications across diverse IT environments, he noted.

As DevOps continues to evolve, it’s apparent that legacy categories such as application release management are going to be subsumed into larger software development lifecycle frameworks based on best DevOps practices. The debate many organizations are currently engaged in is determining how much they need to change their IT culture before acquiring the tools and platforms required to successfully adopt DevOps. However, Labourery said this “chicken and egg” debate overlooks the importance of getting the tools to the teams that need to make the transition to DevOps occur. Otherwise, IT leaders will find themselves advocating for a theoretical cultural change without creating the opportunity for anyone to gain hands-on DevOps experience, he noted. In short, there’s no substitute for on-the-job DevOps training.

A consolidation of DevOps vendors is underway. In some cases, those acquisitions will be driven by leaders in a category, such as CloudBees. In other cases, providers of software development tools commonly used in legacy application environments will need to extend their reach further into the realm of DevOps. IT leaders, going forward, will need to consider carefully just how and where they want to place their bets, at a time when DevOps teams tend to add and discard DevOps tools, often with little to no regard for any larger IT strategy.

For more insight on the CloudBees/Electric Cloud acquisition, check out Alan Shimel’s video conversation with Sacha Labourey.

— Mike Vizard

April 18, 2019
DevOps and Security: Be Ready to Shield Your Application
All of us have heard of continuous improvement/continuous delivery (CI/CD). There are many benefits to implementing CI/CD, as it helps seamless integration from end to end for development and deployment processes. CI/CD helps in rapid improvement, shorter release cycles and more, but it also helps with the challenge of handling security effectively at DevOps speed.

Tools for Securing DevOps

There are thousands of DevOps security tools available in the market that help us at HCL Technologies secure our software development at various stages of the CI/CD pipeline. There are new vulnerabilities rolling out daily, and so we must be alert and keep our applications safe and future-ready.

These are the DevOps security tools we use (most tools are open source with an option of enterprise edition):
1. OWASP SonarQube
2. OWASP ZAP
3. OWASP Dependency-Check
4. OWASP Glue
5. Anchore
6. Clair-CoreOS
7. FOSSA
8. Cyberark Conjur
Our DevOps Toolchain Diagram

Securing CI/CD

Let’s consider a job in which we check out the code from GitLab/GitHub with auto-commit (a Jenkins job will be triggered as soon as the developer makes any changes in the code). You can refer to this link for more information about Jenkins GitLab automation.

Now, in Jenkins, we can run a security test and present it in the form of reports and dashboard to meet our needs. To get started, we can use OWASP SonarQube for static analysis. OWASP SonarQube includes found bugs, PMD and several security plugins bundled out of the box. Next, for dynamic analysis and penetration testing, we can use OWASP ZAP, which presents reports in XML/HTML format that can be used to create Jira issues.

In the above scenario, we can also use ZAP through custom tools integration. In our case, we have installed ZAP on our local machine. We can also use OWASP ZAP installed in a remote machine.

Steps for Remote OWASP ZAP Connection

Windows Command: C:Program FilesOWASPZed Attack Proxy>zap.bat -config api.disablekey=true -config api.addrs.addr.name=.* -config api.addrs.addr.regex=true

Linux Command: Zed Attack Proxy>zap.sh -config api.disablekey=true -config api.addrs.addr.name=.* -config api.addrs.addr.regex=true

OWASP Configuration in Jenkins

The reports will be generated in .xml and .html format. Now, with the reports generated by ZAP, we developed a Java program to create Jira issues for every vulnerability detected and assign it to the concerned person.

Next, we have OWASP Dependency-Check analysis on our project. To configure for Jenkins, follow these steps:

First, we need the OWASP dependency-check plug-in (which I have already installed). This process may take several minutes, as it downloads from NVD server.

Here are the next steps:

Alternatively, we can use the OWASP Glue plug-in, which runs OWASP ZAP, OWASP Dependency-Check and other security automated tests.

We have also used FOSSA in our projects for license audits and vulnerability management for OS dependencies. We can use FOSSA as on-premises, but it is available only for use on Ubuntu machines.

At HCL, we are currently working on container security with Anchore and Clair-CoreOS. We have also integrated identity access management (IAM) to our CI/CD jobs. As for IAM, we are working on CyberArk Conjur and HashiCorp Vault.

CyberArk Conjur

The Conjur Jenkins credentials plug-in:

HashiCorp Vault

Conclusion

I have worked on various tools for security with DevOps. Below is a quick comparison of the tools that can be used for application security.

Now that you have an idea of which tools to use, embrace security instead of worrying about it. DevSecOps can help improve and increase the outcome and effectiveness of any organization.

— Debarghya Pandit
April 16, 2019
5 Practical Ways to Deliver Secure Software That Could Actually Work
Almost every aspect of modern life is dependent on technology. As technology becomes even more advanced and pervasive, so, too, does the need for secure software.

Today, even the tiniest breach at an organization could result in major loss of sensitive data. Therefore, it is crucial for both the reputation and proper functioning of the organization to have steady security measures in place.

Below are five practical ways organizations can deliver secure software by prioritizing safety and maintaining a sustainable “security culture.”

Organizations Build and Foster a Healthy Security Culture

A security culture, just like any other culture, thrives when it is used actively. Effective security culture is a one-time investment that can reap major benefits. However, it requires effort from the organization.

A viable security culture is based on four key features:
- The security culture is disruptive in nature and brings about immediate change.
- Security practices employed by the organization are engaging for everyone, not just the security department.
- A proper reward system is in place for the people who actively take part in security regimens.
- Investments made into the security culture are returned in one form or another.
Ensuring that a proper security culture is in place takes care of the biggest problem in the development of software—humans.

The establishment of a robust security culture helps humans in an organization more than it does the computers. It provides a proper framework through which employees at an organization can act to maximize security.

Some ways to develop the security culture at an organization include:
- Instill the belief into the employees that security-related issues are not just the headache of the security department; rather, the whole organization should work together to resolve them.
- Focus on spreading awareness throughout the organization by providing employees the basic security knowledge.
- Provide opportunities for advancements in security to team members who are more excited.
Despite having a strong security culture in place, however, breaches may happen. A proper security culture can help the organization recover more swiftly.

Acquire a Secure Developmental Life Cycle

A secure developmental life cycle (SDL) provides a firm foundation to monitor the security practices in an organization.

An SDL performs essential functions such as threat modeling, security analysis and requirements, and carries out security testing. The organization that acquires the SDL agrees to an in-depth study of their security on all the software and system releases.

Microsoft, for example, offers a free SDL that consists of security practices that could help organizations regardless of their size or platform. This is especially useful to those organizations that have just started.

Other benefits of having an SDL are:
- Detects bugs in the software earlier in the development cycle, which is cost-effective.
- Safeguards the interests of the stakeholders and investors, as it makes the business secure.
Overall, an SDL minimizes the risks that an organization faces and helps in advancing it.

Integrate Security Tests Into the Developmental Phase

Organizations should introduce security tests in the developmental period; that is, when the code is being written or when the programmers check in on their codes.

The introduction of security tests allows developers to correct their mistakes at an early stage, which effectively reduces the cost of resolving the problem. Developers actively get feedback, enabling them to design software with a smaller number of flaws.

Moreover, tests conducted at the developmental stage save time and keep the disruption caused by the whole developmental process to a minimum.

Have a Deep Understanding of What’s in Your Software

Developers should work with security experts to understand the software and the applications installed.

Knowing what constitutes applications—especially open source applications—is pivotal in patching any discrepancies that may arise.

Along with a firm grasp on the software, developers must be aware of application security.

Application security, or AppSec, teaches advanced lessons to the testers and developers within an organization and aids them in building secure products and services.

Encourage Mentorship

No security system is complete without a set of security experts who can train developers in specific methods and procedures. These mentors can be responsible for conducting security tests and furthering the advancement of secure software in an organization.

Mentors can also provide a learning experience to the staff members and go the extra mile to make sure security is accessible for everyone.

Conclusion

Organizations need to maintain a standardized way of delivering software. The threats we face today, if not dealt with, can have dire consequences.

However, the solution starts at the very beginning and needs to be integrated into everything related to software, from education to the way employees interact with each other in the workplace. Only then can we rest easy knowing our software and data are protected.

— Zehra Ali
April 16, 2019
Effective Cloud Security Requires a Cloud-Native Mindset

Thousands of developers and cloud security professionals will fill the Moscone Center in San Francisco next week for the sold-out Google Cloud Next ’19 conference. Three days of breakout sessions and keynotes will immerse attendees in deep technical content and opportunities for hands-on learning. It’s all designed to help organizations embrace the cloud. A key element of succeeding in the cloud is cybersecurity. More critically, the cloud demands embracing a cloud-native approach to security challenges.

Leading the Way

Since its inception, Google has been pushing the envelope and blazing trails in the cloud. Like Netflix, Google found itself—and often continues to find itself—in uncharted territory, where it was forced to innovate original solutions to address unique challenges.

To help create standards and tool sets for managing container environments, Google joined the Cloud Native Computing Foundation (CNCF)—a melding of minds between developer communities and platform vendors—as one of the founding members along with CoreOS, Docker, Cisco, IBM and others. Famously, Google also originally developed Kubernetes—an open source container orchestration system for automating application deployment, scaling, and management.

Google eventually donated Kubernetes to the CNCF. Transitioning it from a Google project to a CNCF project helped it gain broader traction and momentum and emerge as the de facto standard for container orchestration. Kubernetes became the first CNCF project to graduate out of incubation.

Cloud-Native Mindset

Kubernetes is a powerful, scalable platform for deploying and managing container environments of all sizes. Still, security needs to be a core focus for organizations, even in a Kubernetes ecosystem. The nature and volatility of container-based applications and cloud environments requires security to be cloud-native as well. Deploying containerized solutions on Kubernetes requires security that is built in to the distributed infrastructure and puts the focus on API security.

Automation is Key

The word “dynamic” is a very polite way to describe most cloud environments; volatile or chaotic might be more accurate, in many cases. Cloud infrastructures typically leverage DevOps tools and principles to compress development and deployment time frames and expedite the process of iterating new versions with continuous integration (CI) and continuous deployment (CD).

The thing is, when development is driven by a CI/CD pipeline, security has to be as well. Manual processes can’t possibly keep up with the volume of assets that need to be monitored and protected, and traditional cybersecurity tools are not equipped for hybrid or multi-cloud environments. What’s more, they lack the scalability necessary for effective cloud security. Implementing and managing security in an environment that is constantly shifting and evolving requires an automated, cloud-native approach.

Security in this context should be managed via API and also optimized to test API-based applications. Speed is crucial as well, though. Security should not break or impede the CI/CD pipeline due to timeouts or delays.

Kubernetes clusters need cloud-native security tools to automate application protection. Tools capable of protecting containerized applications, microservices and APIs across public and private cloud environments while minimizing false positives at the same time.

Conclusion

There will be a ton of great information shared at Google Cloud Next ’19. While you’re networking, gathering insights on cloud strategies and learning how to solve problems in the cloud, don’t forget the crucial role of security. There are a variety of sessions offered that focus on security—how to manage, deploy, and develop security models for the cloud. Or, take a walk through Google’s dedicated Security Area in Moscone Center’s South Exhibition Hall. It’s a great place to connect with experts and educate yourself on why cloud-native solutions are essential for effective cybersecurity in a cloud ecosystem.

— Tony Bradley

April 5, 2019
How to Design DevSecOps Compliance Processes to Free Up Developer Resources
Anything that gets rolled out quickly in the technological world is a major step forward—as long as it doesn’t compromise security.

DevSecOps is able to provide compliance processes far more effectively than before, and without jeopardizing security while also freeing up developer resources.

How do you direct your IT team to keep your applications and customers safe without completely draining your resources in the process?

The answer: automation.

Why is Security Vital to DevSecOps?

To take full advantage of the agility and responsiveness of DevOps, you must bring forward an IT security team through the entire life cycle of your apps.

In the past, when software could take months or years to complete, it was perfectly acceptable to bring in the security team in the final stage of development. But in the days of DevOps, a security team must get consulted from day one due to rapid and frequent development cycles.

An effective DevSecOps system can be completed in days, so the outdated approach to handling security during the development phases also must change.

How Did Security Radically Change DevOps?

It is important to remind developers that security is a shared responsibility that must be integrated from end to end to guarantee a smooth and functional application. The mindset is so important that many have changed from using the term DevOps to DevSecOps to stress the importance of the need to build a very sound security foundation.

If you are already making the transition to the cloud with AWS, chances are you have already implemented DevOps strategies into your interface so you can test new virtual machines (VMs) and deploy applications quickly without waiting for infrastructure to get manually configured.

For those who prefer the old-school method of developing applications, neglecting security until the end leaves their applications exposed. One of the most common security issues with most SMEs is misuse of security during beta tests, which is basically akin to leaving your front door wide open when you go to sleep at night. It’s just a terrible idea.

Making the transition from DevOps is not a luxury but a necessity for developers who want a secure environment, even during the dev/test period.

Designing Compliance Processes for IT

Even if you add “security” to the term DevOps, it means little without properly adding the processes you use into the building of the applications.

Security must be built into the processes by design, or you are not correctly taking advantage of what DevSecOps means—and your developer resources will get neglected, too.

Like the name implies, security must be in the center of development and operations. To maintain compliance, you must enforce a shared responsibility between AWS and the customer:
- AWS is responsible for security of the cloud, including the hypervisor and hardware.
- Customers are responsible for security in the cloud. They do this by securing your applications and network with services through a third-party vendor.
The best examples of DevSecOps in the cloud take this philosophy to heart.

Automation is Critical to Compliance Processes

A “security first” mentality is good , but are you really taking action with your compliance processes to free up developer resources?

The answer for many developers is, “Not quite.” Automation is essential to DevSecOps, yet so many systems lack the right tools. This is especially unfortunate for organizations that have the necessary skills and procedures in-house to implement built-in security processes directly into the application by design.

For other organizations, automation is only achievable by leveraging their services from a security integrator, who can then provide services to help define processes and roles, unveil security tools and set up automation procedures.

Steps to Establish Automation on DevSecOps

Now that you know automation is crucial to the success of any system, here are a few basic steps you can take from day one to start building the security processes into your design:
1. Consider a “shift-left” mentality when adding new processes, ones that incorporate design thinking from customers’ security needs and remain consistent. Steps such as threat-modeling storyboards build cyber resilience into the application before the first code is even written.
2. Consider a cloud-based vulnerability scanning solution. It will help you define standards for the AMI as well as validate adherence to those standards.
3. Implement an audit, logging and monitoring solution to track changes to the in-use AMIs. It helps combine account activity and AWS resources from the cloud with data related to security incidents. The in-use AMI changes can do everything from providing ongoing insights to allowing other security controls and having influence over network security.
4. View the AWS Marketplace catalog. Along with what an internal staff or a systems integrator can help automate, there are a number of other terrific resources out there for automation. The software listings are all from independent software vendors that make it straightforward to locate, test, buy and deploy software that runs effectively on your AWS environment. Like other AWS services, the providers are billed based on consumption, so you pay only for what you need.
By asking yourself the important question, “What am I trying to accomplish with my security controls?” you can get a variety of answers regarding what measures you need to take for compliance processes.

Final Thoughts

Speed, speed, speed. Developers today simply have no time to waste when it is time to launch new applications and get them out the door.

You have little time to burn on extra features, but you also can’t afford leaving your systems exposed and vulnerable to attacks. That’s why DevSecOps uses superior security processes to free up developer resources by utilizing as much automation as possible.

— Sam Bocetta
April 3, 2019
4 Steps to Introduce DevSecOps to Database Development

Although DevOps was implemented within application development, there is a growing awareness that including the database within DevOps processes is vital to success. We live in a data-driven world and many front-end applications use a database at the back end to collect, process and store customer and user data.

The faster development of applications that DevOps encourages also results in more frequent updates to databases. By excluding database development from DevOps, the database becomes a counterweight to the speed of releases that otherwise can be gained.

This is already being recognized, as demonstrated in the 2019 Database DevOps Survey from Redgate, which found that 77 percent of application developers are now responsible for database development and 75 perent build database deployment scripts.

All of which is welcome news, provided DevSecOps for the database is also taken into account.

While DevSecOps is relatively new (the term was coined in 2012 by Gartner analyst Neil MacDonald), the need for it is a widely accepted facet of DevOps because DevOps radically changes how companies tackle security in application development. Whereas security used to be reviewed and certified at the end of long development cycles with a scheduled window, that window has now disappeared. Hence the rise of DevSecOps, which bakes security into the development process, with tools such as static code analyzers and open source code vulnerability scanners testing code as soon as changes are made.

In the same way that the database must be included within DevOps if the process is to be seamless, companies also need to ensure that DevSecOps is applied to the database. In fact, given the importance of protecting personal data in today’s world, ensuring privacy and security is imperative for both compliance and public reassurance.

In 2017, MacDonald continued his work on defining what DevSecOps is when he set out 10 steps that companies need to follow to protect applications during development. All of these are equally relevant to DevSecOps for the database, with the exception of the second step: Quit trying to eliminate all vulnerabilities during development. Many databases contain personal data, much of which is sensitive, so every vulnerability during database development has to be addressed and resolved.

Looking in detail at Gartner’s list, I’d say there are four key steps that particularly apply to DevSecOps for the database:

Identify the Vulnerabilities

At the center of DevSecOps for the database is the data, which has to be protected from both internal threats such as negligence or accidental exposure, and external threats such as hacking. The biggest problem with data, however, is its size and sprawl. Data is growing at an annual rate of 58 percent, according to IDC, and is now stored in a multitude of different places.

To identify what the vulnerabilities are, the data first needs to be located and classified and its risk identified. Data mapping exercises such as this can be done by hand or with a third-party tool, but it’s important to create a record of every database, including copies used in development or testing, to gain a real understanding of where data is stored and who has access to it. Classifying the data then can be undertaken to identify which data is sensitive and at risk, such as credit card details, and therefore needs to be protected.

Remove the Vulnerabilities

As we’ve seen, the recommendation to not try to eliminate every vulnerability in application development doesn’t apply to the database. Where data has been identified as sensitive and at risk, access must be limited and it cannot be widely shared.

Developers, however, often need a copy of the production database in their development, test, or QA environments to ensure changes will work once deployed. However, those same production databases invariably contain sensitive data that needs to be protected.

One solution is to create a version of the production database with a limited dataset of anonymous data. However, this means it is neither realistic, nor of a size where the impact on performance can be assessed. A second solution is to take a copy of the production database and mask the data manually, but this will age quickly as ongoing changes are deployed to the production database.

Therefore, data masking measures such as pseudonymization, encryption, anonymization and aggregation should be adopted, and companies can use third-party tools to help mask database copies, yet also provide development teams with test data that looks—and behaves—in the same way as real data.

Introduce Secure Coding

While application development typically uses an imperative programming language such as C# or Java, database development relies on a declarative language, such as T-SQL for SQL Server, which is less strict and where the coding standards vary widely.

This has resulted in developers who code in T-SQL having their own styles and preferences. With multiple developers writing updates, this often ends up with code that is confusing, difficult to understand and with errors that can cause deployments to fail.

To overcome this, code should be written in the same style, with a secure approach that follows set standards, put in place by the database administrator. Introducing this secure coding mindset at the point code is written will prevent problems later down the line.

Automate Where Possible

The ninth point in Gartner’s list is to implement strong version control on all code and components, with developers checking their changes into a common repository during the development process, preferably at the end of each working day. As a result, everyone has access to the latest version of the application, and it is always clear what was changed, when it was changed and who changed it.

This is just as true for the database code, which also can be version-controlled, preferably by integrating with and plugging into the same version control system used for applications.

Importantly, once version control is in place, processes further along the development pipeline can be automated. Continuous integration can be introduced, for example, to automatically test changes as soon as they are committed and ensure they are not breaking changes.

Data has been described as the 21st century equivalent of oil, with its use central to success in every organization. Given its sensitive nature, protecting it is equally vital. That’s why all businesses and teams need to ensure they are not only including the database within DevOps, but within DevSecOps as well.

— Matt Hilbert

March 25, 2019
4 Steps to Improving Your Team’s Continuous Security

A recent npm survey revealed that 77 percent of developers were concerned about the quality and security of the open source libraries they use, while 52 percent said the tools currently available were inadequate. Given the trust issues in open source and the ongoing discovery of website and application vulnerabilities, security should be top of mind for developers at the start of every project—but also on an ongoing basis. I call this practice of constant re-assessment “continuous security.” Here’s how I like to describe it:

Imagine you are standing at the bottom of an escalator that’s moving downward. Your goal is to reach the top. You might think, “Easy, I’ll just sprint my way to the top! Run as fast as possible and I’ll get there, and the problem is solved.”

It’s not that easy, though. As you start your climb, you realize that you haven’t really trained for this and you’re slower than expected. The people traveling down toward you become obstacles to be evaded. Through all this, you have to maintain your upward momentum, or you’ll end up back where you started.

Now, it might sound a little cliché, but that’s how I view security. Security is something you have to continually train for—a constant cycle of risk discovery, prioritization and skill-building to close the gap to get results.

Continuous security is all about becoming more efficient at this entire life cycle and reducing the time to risk discovery and the overall cost of mitigation.

Risk Discovery

The first step to improving your security situation is to find something that needs improvement. These tend to be risks to the business and look different depending on your focus area. For a legal team, that might be license compliance; for a development team, it’s likely to be a security bug in a production service.

When you start out, your abilities to discover risk are going to be pretty poor, but that’s okay. I like to apply this discovery process at the natural gates of the development life cycle. Major ones include: when the feature is designed, when code is first written and when someone makes a pull request, pushes code to staging and pushes it to production. The tooling and techniques you use in each of these stages will vary greatly by the needs of the business and change as your security program matures. There will be arguments continually about what is considered a risk and how it should be prioritized. This is part of the process of refining your risk discovery skills and tools.

Policy and Standards

There is rarely any change without pressure, and because we don’t always have an active incident to force improvement, that pressure sometimes has to come from within. Motivating your team through policies and standards can be the ideal way to influence improvement.

Everyone in your organization will have their own perspective, so developing a strong set of policies and standards to measure yourself against will go a long way. Writing and adopting these standards should be collaborative, both with your security team and the organization as a whole.

These policies help you determine what is a risk and how you prioritize it as an organization. At npm we have a standard rating scale that security assigns to risk (P0 = drop everything and fix critical, to P3 = fix within 180 days). This tells engineering how long each risk should take to mitigate, helping them prioritize their work accordingly.

Mitigation and Improvement

This is where the technical practitioner will have the most fun—fixing lapses in security is usually satisfying work. The important part is to use each incident as an opportunity to scale your efforts in risk identification.

For development teams, that means pushing more automation in your CI/CD pipeline to arm developers to be able to find security issues earlier in the development process. I like to call this the CI/CD/CS pipeline: continuous integration, delivery and security. However, automation is far from perfect, and the best way to improve decision-making is to provide a human with the right amount of information in the right context whenever a decision needs to be made.

An important thing to remember is that your solution does not have to be perfect. There are many situations in security where “better” is good enough to mitigate risk to an acceptable level. In the end, what you need to have is a constant feedback loop of risk discovery and mitigation, using technology and processes to manage and improve.

Continuously Improving Continuous Security

Setting goals and expectations is a part of continuous security, but you should keep in mind that “security” is not a set destination. The word “security” lies to us by suggesting that it’s possible to secure something, when in truth the mitigation of all risk is an impossibility.

Instead, always try to maintain your upward momentum. Measuring all successes and failures honestly allows you to be effective at all times, whether in the middle of a security issue or a period of relative calm. A continuous, proactive approach to security is the only way to effectively ensure the safety of developers and code.

— Adam Baldwin

March 14, 2019