devopsy.kinsta.cloud

Tag: application security

Report Finds Most Cloud Security Issues Left Unaddressed

Accurics, a provider of a platform for assessing the security of cloud computing environments, has published a report that finds that even once discovered, only 4% of issues reported in cloud production environments are addressed.

Based on research conducted using its platform and other public sources of data, the report also finds 90% of organizations allow privileged users to make configuration changes directly to a cloud infrastructure after it is deployed.

Issues such as open security groups, overly permissive identity access management (IAM) and exposed cloud storage services make up 67% of the most common cloud security issues being uncovered, according to the report.

The Accurics report echoes similar findings published by Unit 42, the cybersecurity arm of Palo Alto Networks, which found more than 199,000 templates have medium-to-high vulnerabilities in use on public clouds.

Accurics CEO Sachin Aggarwal said that as more organizations embrace infrastructure as code using tools such as Terraform, policy guardrails aren’t being put in place. More troubling still, security assessments seem to be few and far between. That’s especially problematic because cybercriminals now routinely probe every layer of the application stack looking vulnerabilities, he noted. In effect, cybercriminals are assessing cloud applications and infrastructure more frequently than IT teams.

Aggarwal said beyond making sure the appropriate guardrails are in place in terms of overall security posture, organizations need to have confidence in the DevOps processes being adopted. That doesn’t mean cybersecurity teams should put rules in place that slow that application development process down. Rather, tools that surface cybersecurity issues and then provide a method to automate the remediation of any vulnerabilities discovered need to be put in in the hands of IT professionals, he said.

The challenge organizations face is the processes that are employed to secure on-premises IT environments largely don’t translate well to highly dynamic cloud computing environments that assume a shared responsibility approach to IT. Public clouds are obviously popular with DevOps teams that can programmatically invoke resources on demand. However, those teams generally don’t have much cybersecurity expertise. Too often, DevOps teams assume cybersecurity tasks are being handled by a cloud service provider. Of course, the cloud service provider is only securing the services they provide. Any configuration issue is not their responsibility.

The result is as more changes are made to the IT environment, the more likely that mistakes will be made. Catching all those issues without the aid of tools is an unreasonable expectation for any IT organization, much less a DevOps team that may be working beyond the purview of the rest of the IT organization.

No one sets out to create a cybersecurity issue. But in the rush to deploy or update an application it’s easy to overlook a cybersecurity issue. The goal should be to eliminate as many of those mistakes as possible before they are ever made. However, as long as humans are involved, there will be errors. So the next most important thing is to be able to correct those mistakes as quickly as possible without having to disrupt the entire IT environment.

May 29, 2020
The Best Approach to Help Developers Build Security into the Pipeline

Speed and agility are at the core of digital transformation and DevOps culture, and have quickly become a business imperative for organizations that want to remain competitive. Speed cannot come at the sacrifice of security, though. The pace of software development requires that security be baked into the code from the start rather than tacked on after the fact. Developing secure code fast requires empowering developers with the skills and tools they need and building security into the DevOps pipeline.

Embracing DevSecOps

DevOps culture and the drive to work faster and more efficiently affects everyone in the organization. When it comes to creating software and applications, though, the responsibility for cranking out code and producing quality code falls on developers.

The pace of DevOps culture doesn’t allow for anything to be an afterthought. It’s important for developers to support security directly as a function of application development in the first place, and to operationalize security within the continuous integration/continuous deployment (CI/CD) pipeline.

Unfortunately, traditional education does little to prepare them. It’s possible to get a PhD in computer science and never learn the things you need to know to develop secure code. As organizations embrace DevSecOps and integrate security in the development pipeline, it’s important to ensure developers have the skills necessary. You also need to focus on both the “why” and the “how” in order to build a successful DevSecOps training program.

Don’t Just Check the Box

Not all training is created equal. Consider why you’re doing the training and the outcome you hope to achieve rather than doing training for the sake of training. Many organizations focus on training developers in secure coding practices from the perspective of compliance. It’s crucial to engage developers in a meaningful way, though, and not just check a box.

Many compliance frameworks, such as PCI-DSS, require ongoing application security training, but compliance training often reinforces the wrong lessons. Developers learn the most expedient way to check the box and achieve compliance rather than learning the most efficient way to develop secure code. This approach also causes developers to feel like the security team looks down on them or doesn’t understand the challenges they face or the expectations they have to meet.

The Carrot and the Stick

How you do security is also important. Training works better when developers feel like they are part of the process and when they have a reason to want to excel.

For nearly everyone, doing something in practice reinforces lessons better than just reading content or listening to a webinar or video. Interactive labs are more engaging and provide feedback as developers go through the training. They can practice writing secure code with guided practice that is self-paced. They can also get hands-on experience exploiting vulnerable applications, then patching them back up.

You should implement developer training that creates incentives for developers by gamifying training. Create custom Capture the Flag events, track individual progress and provide a leaderboard that enables healthy competition among the developers.

You also want to provide developer training that is relevant to your organization’s preferred coding languages and business objectives. The training should teach skills and strategies that are applicable to the code your developers work with and give them tools they can use immediately to improve the security of the applications they’re working on.

Speed is essential for businesses to maintain a competitive edge today, and security is more important than ever. Make sure you have the training in place to help shift application security knowledge left and integrate security to mature DevSecOps practices.

May 25, 2020
5 Ways to Detect Application Security Vulnerabilities Sooner to Reduce Costs and Risk

Security testing has always been an important step in the application development process. Yet, traditional measures often occur too late in the process to effectively find and fix vulnerabilities before causing costly production delays, or worse, putting organizations at risk for potential security breaches.

To minimize security-related costs and risks, testing needs to occur sooner and more frequently throughout the development process. But, how can you accomplish this while keeping pace with growing application development demands?

Looking at automation can help. Development teams have been using automation to streamline manual activities such as build, deployment and functional testing for years now, and it is time security testing joins the mix. By integrating automated security validation into the continuous integration/continuous development (CI/CD) pipeline, you can catch vulnerabilities sooner, reducing the potential risk and financial impact.

In this article, we’ll look at five ways automated technology tools can help safeguard the CI/CD pipeline: SAST, detecting OSS vulnerabilities, identifying compromising credentials, DAST and verifying cloud infrastructure security.

Your CI pipeline provides a ready-made check-in point to install the following automated security gates and pinpoint vulnerabilities.

Static Application Security Testing (SAST)

SAST provides the earliest check-in opportunity, allowing you to identify potential issues at the coding stage, so you can resolve problems without breaking builds or allowing vulnerabilities to get passed to the final application release.

Commercial solutions such as Checkmarx help to identify hundreds of security vulnerabilities and weaknesses in custom code. You can also leverage many open source linters for your specific platforms to detect various vulnerability patterns that can compromise code security.

Detecting Open Source Software Vulnerabilities

Just because the code is secure doesn’t mean the entire application is protected. Most applications use a large number of dependencies, or third-party open source software (OSS) components. These may have various security vulnerabilities and put your application at risk.

Tools such as Whitesource Bolt and Black Duck can scan all of your projects, not only to detect OSS components, but also identify and provide fixes for any known vulnerabilities.

Identifying Compromising Credentials

Human error is always a security concern, especially when it comes to credentials. Just consider how many times you’ve heard of developers committing code only to later realize they’d accidentally included a password. These errors can lead to high-cost consequences for organizations.

There are many tools that scan for secrets and credentials that can be accidentally committed to a source code repository. One example is Microsoft Credential Scanner (CredScan). Perform this scan in the PR/CI build to identify the issue as soon as it happens so they can be changed before this becomes a problem.

Once an application is deployed, you can continue to scan for vulnerabilities through the following automated continuous delivery pipeline capabilities.

Dynamic Application Security Testing

Unlike SAST, which looks for potential security vulnerabilities by examining an application from the inside—at the source code—Dynamic Application Security Testing (DAST) looks at the application while it is running to identify any potential vulnerabilities that a hacker could exploit.

OWASP Zed Attack Proxy (ZAP) is an open source tool for performing pen testing on web applications and APIs. Pen testing helps ensure that there are no security vulnerabilities hackers can manipulate. It can be installed as a client application or come configured on a docker container. OWASP ZAP scans can be incorporated into your pipeline to check every deployment for security vulnerabilities.

Verifying Cloud Infrastructure Security

Finally, in addition to validating the application, the infrastructure should be validated to check for vulnerabilities. When using a public cloud, deploying the application and shared infrastructure is easy, so it’s important to validate that everything has been done securely.

Each public cloud includes tools to help verify that the infrastructure has been provisioned securely. APIs can be leveraged to check immediately after deployment in lower environments to help ensure any infrastructure security issues are caught before they get to production. Additionally, tools such as InSpec provide compliance-as-code to enforce the intent of provisioned infrastructure is always being met.

Enabling continuous security validation through the CI/CD pipeline can help fortify applications against an expanding array of security threats that can lead to significantly higher costs and exposure. At the same time, automation tools can provide added layers of protection while meeting the organization application development demands.

May 19, 2020
Fortanix Adds Platform to Manage Confidential Computing on Azure

Fortanix today announced that a software-as-a-service (SaaS) platform for managing instances of confidential computing on the Microsoft Azure cloud is now generally available.

Confidential computing is an emerging approach to encrypting data while it is running in memory. Today encryption is only applied to data at rest. Confidential computing makes it possible to set up secure enclaves for processing encrypted data in memory, which has become an increased source of concern for vulnerabilities in IT environments.

Faiyaz Shahpurwala, chief product and strategy officer for Fortanix, said Confidential Computing Enclave Manager provides IT teams with a SaaS platform that enables them to provision a confidential computing environment, verify the integrity of those environments and manage the application life cycle for secure enclaves. Applications running on secure enclaves are built using Docker containers and images.

Fortanix, along with Alibaba, Arm, Baidu, Google Cloud, Huawei, Intel, Microsoft, Red Hat, Swisscom and VMware, is a member of the Confidential Computing Consortium, an arm of The Linux Foundation. Confidential Computing Consortium projects include a Software Guard Extensions (SGX) software development kit (SDK) from Intel, an open source Open Enclave framework that allows developers to build Trusted Execution Environment (TEE) applications using a single enclaving abstraction, and Enarx, a project providing hardware independence for securing applications using TEEs.

Microsoft earlier this month made available a DCsv2-series of virtual machines (VMs) that provide access to a TEE based on Intel SGX. Fortanix, for its part, already makes available a Fortanix Self-Defending Key Management Service on Azure.

Shahpurwala said over time most applications will take advantage of trusted computing environments. Most of the initial use cases will focus on applications in which data privacy and securing personally identifiable information (PII) is critically important, he said.

In the meantime, cloud service providers are racing to make available platforms for building and deploying TEE applications. Less clear is to what degree those environments will be integrated with DevOps platforms. The Confidential Computing Enclave Manager provides a management framework from which to begin that process. The Confidential Computing Enclave Manager also provides tools to convert applications to enable them to run on Intel SGX.

There may come a day when confidential computing makes security a core element of any DevOps process. As such, the idea that there needs to be a distinct approach to DevSecOps may in time fade away as security becomes a series of infrastructure capabilities that are invoked programmatically. As that approach matures, application security would simultaneously evolve to become a natural extension of any quality assurance process.

Of course, it may be a while before confidential computing is employed pervasively. Not every IT team has made the switch to containers to build applications. However, given all the focus these days on data privacy regulations it’s clear the requirements for protecting data within an IT environment are becoming more stringent with each passing day. The challenge now is finding a way to address those concerns during the entire application lifecycle management process in a way that doesn’t slow down the rate at which applications are being built and deployed.

May 18, 2020
The Secure Software Development Life Cycle: Syncing Development and Security
Over the last five to 10 years, the nature of software development has shifted dramatically. Whereas large software releases occurred every six to 18 months in the past, current release schedules have become much more frequent. The waterfall model of software development has morphed into what we now know as the DevOps model.

As a consequence, DevOps has instigated changes in the traditional waterfall security touchpoints. In essence, DevOps has changed the very nature of how application security needs to be implemented. To avoid friction in the development process, application security activities must be adapted to the new world of DevOps practices. It has to go beyond the basics of threat modeling, design review and two weeks of pen testing.

Under DevOps, some development organizations now do software releases on a daily, weekly or bi-weekly cadence. But they’re still grappling with older application security models. As a result, development and security testing can be out of sync—you cannot conduct a two-week pen test on software that’s released weekly. These organizations need effective security assurance in their SDLC that’s good, quick, early and—above all else—automated.

The Changing Nature of Software Development

The way software is developed keeps changing. And it keeps accelerating. Application security needs to change to catch up. Automation will play a key role in enabling application security to maintain the pace of DevOps. DevOps needs automation to effectively deal with software release cadences that occur on a daily, weekly and bi-weekly basis as well as to increase agility generally within the SDLC.

For example, DevOps accelerates when the automated pipeline embeds application security scanning into pre-commit checks. In this way, consistent levels of application security testing apply every time developers check in code, resulting in a fully automated check-in process. But automation doesn’t lock developers into the same level of security for every code change. For example, if the change only involves altering the color of a logo, heavy security scanning and manual won’t be necessary. At least not the way it would be if the application is accessing sensitive data.

So, instead of giving developers quarterly SAST results, automation puts the code analysis right there in front of developers as they’re checking in code (via certain IDE plugins). Presenting the code analysis findings to developers, while they are still in the code, has several advantages:
- The code is still fresh in the developers’ minds.
- Coding problems can be caught earlier and more easily while developers are still thinking about the code.
- It mitigates the risk of developers not remembering the code context at a later date.
Overall, the more automation there is in application security the better it is for open source validation, container scanning containers, QA testing, API security and more.

Automated Security Assurance and Out-of-Band Activities

When it comes to implementing testing in DevOps, you must balance automated security assurance with out-of-band activities. That means it’s sometimes appropriate to slow down the automated security process. Even in a completely automated DevOps process you may need to slow down to make necessary changes. It’s true a code change, such as just changing the background color on a web app, may not be too risky. There’s no problem with automating that DevOps step and pushing out the change. But, if your web app interacts with customer data, you’d be prudent to slow down and take the next application security test out of band, and make sure you’ve got the procedure right because it’s much riskier.

There are different levels of risk and severity within each release of an application. Development organizations need to accept this and adapt to each release’s potential risk and severity level. Then, they need to provide the appropriate level of security assurance and security coverage, whether that is automated within the DevOps workflow, performed out of band or some combination of the two.

Life in the Fast Lane

For DevOps organizations, one of two avenues beckons to them: the security express lane or the security slow lane. You could create an automated DevSecOps process across the development organization—the security fast lane. But, there’s no one-size-fits-all DevSecOps process for enterprises. That’s because there could be up to hundreds of development teams within an enterprise. And there’s not always a standardized process that all dev teams can follow. It’s a challenge to adapt automated security to each development team. Those in the security fast lane should use a security champion to work with the development team and be the point person to assist them with understanding application security needs and remediation guidance.

In the security slow lane, individual development teams may still be enabled to go fast. The difference is that they will pick the SDLC tools that make the most sense for that team. Then, they should also pick the application security tools that make the most sense for them. The bottom line for organizations is that application security needs to involve an acceptable level of friction for developers to make DevSecOps work. If there is too much friction, developers will bypass application security in favor of expediting coding activities.
May 13, 2020
Survey Surfaces Root Causes of DevSecOps Tension

Results of a survey published by SaltStack, a provider of IT automation tools, suggests tensions between cybersecurity and IT professionals on the one side and DevOps teams on the other are running high. According to the survey of 130 cybersecurity and IT leaders, 70% of respondents said their organization is sacrificing data security for faster innovation, with most cybersecurity and IT managers making a case for prioritizing data protection over innovation, speed to market and cost.

Alex Peay, senior vice president for product at SaltStack, said that while it’s unlikely cybersecurity and IT leaders will be able to slow down the pace of innovation within their organizations, the survey results make it clear IT organizations are struggling to keep pace.

On the plus side, the results also show that cybersecurity and IT operations teams are working more closely together. More than half—54%—of cybersecurity leaders said they communicate effectively with IT professionals, while 45% of IT professionals concurred.

Best DevSecOps processes are, of course, meant to bridge the divide between DevOps teams and the rest of the IT organization. The expectation is that by pushing more responsibility for cybersecurity to the left, the pressure on cybersecurity and IT teams would be reduced. However, DevSecOps adoption remains nascent at best—many DevOps teams still don’t have the tools required to implement security controls programmatically within their applications.

Even when they do have the tools needed to add security controls, organizations need to set up workflows that will enable cybersecurity teams to verify that those controls have been properly implemented. Given the chronic shortage of cybersecurity expertise, the rate at which applications are being deployed and updated easily overwhelms the amount of time cybersecurity teams have available to analyze modules of code that are now often updated several times a week. Most cybersecurity teams are already struggling to keep pace with patches for existing applications, let alone any new application modules.

Of course, there’s not a lot of love lost between developers and cybersecurity teams. DevOps teams generally blame cybersecurity teams for slowing down the rate at which applications are deployed. In fact, one of the primary reasons DevSecOps is gaining traction among developers is that it represents a way to remove cybersecurity professionals from the application development process.

Cybersecurity professionals, conversely, often view application developers as the root cause of the cybersecurity problem. Too many developers are reusing modules of code without first making sure those modules have been updated to address a known vulnerability. To add insult to injury, whenever a new vulnerability is discovered days, weeks or even months may go by before developers address it. To be fair, however, cybersecurity professionals are not especially adept at prioritizing vulnerabilities; as far as developers are concerned, the list of vulnerabilities presented is just one in a series of bugs that need to be addressed. Unless otherwise directed, developers will focus on bugs that impact features and performance before a potential security issue that has yet to manifest itself as an issue impacting end users.

In general, advances in DevSecOps are being made that should provide some much-needed relief to IT and cybersecurity professionals. It’s just slowing down the rate at which applications are deployed and updated might not be one of them.

May 7, 2020
Sacrificing Security for Speed: 5 Mistakes Businesses Make in Application Development

Earlier this year, the Democratic party in Iowa announced its plans to use a smartphone app to calculate and transmit their caucus results. Using technology to improve the speed of governance, one would think, “What could possibly go wrong? A lot, apparently. The app’s failure on results day was attributed to reporting and coding issues.

While security was the matter of concern from the day of its announcement, the inevitable happened. Data and security breaches happen almost every minute. University of Maryland researchers find cyberattacks every 39 seconds. The last decade has seen many data breaches, putting personal information of billions of users in the hands of dubious entities. Every enterprise, from Yahoo to Facebook and Target to Home Depot, has been under attack—and this is likely to continue. Research has found that cybersecurity breaches will result in over 146 billion records stolen by 2023.

Poor security is putting enterprises, governments and citizens at risk every day. Yet, in a hurry to leverage technology, companies bring unsecured applications to market all the time. In essence, they sacrifice security for speed. Adding to this, today’s modern web and mobile applications are built with latest and greatest technology stacks and frameworks, heavily reliant on client side functionality, and integration to multiclouds and third party systems using a myriad of APIs. Also teams are more diverse and work collaboratively using remote workforces.

These trends increase the security challenges the application development teams need to be aware of, and leverage platforms that provide built-in controls and protection against these to avoid security breaches and attacks.

While prioritizing speed over security in application development take into consideration the following mistakes that you need to avoid and address.

Not Looking at Data Security Holistically

Data tends to be the most important and valuable aspect of modern web applications. Poor application design and architecture leads to data and security breaches. Application development teams generally assume that by providing the right authentication and authorization measures to the application, data will be protected. This is a misconception. Right measures to provide data security involve focussing on data integrity, fine grained data access and encrypting data while in rest as well as in motion. In addition, data security needs to be looked at holistically from the time the request is made to the time response is sent back across all layers of the application runtime.

Not Considering Security Across the Application Development Lifecycle

Today’s modern web applications are highly sophisticated and built with a big focus on simplistic user experience combined with high scalability. This combination can be challenging for application development teams from a security perspective. Most development teams focus only on silos when securing the application (only client, server or integration layer). Teams should focus on end-to-end full stack security when developing applications. Also application teams should enforce security best practices incorporated by default as part of the collaborative development process.

Not Focusing on API Security

Most of the modern web applications use APIs from systems and services which include internal enterprise systems, cloud SaaS APIs, partner APIs and third party product APIs. Today, almost all web applications tend to expose their own functionality to the external environment as a core set of APIs. What’s more, nearly 100% of web applications today tend to expose its own functionality as a core set of APIs to the external world. Teams need to make sure they are using external APIs with proper security guidelines and protocols as well as exposing their own APIs with multiple choices of protecting them. API access needs to be protected with both coarse grained as well as fine grained measures.

Not Providing Strong Authorization and Authentication Methods

Authenticating your application and authorizing what users can access is an important part of application security. Without this, you are leaving your attack surface wide open. Your application needs to incorporate stringent and strong measures for authentication to prevent unauthorized access. This includes multi-factor authentication, passwordless authentication, single sign on and if using passwords very strong password policies. It must also offer fine grained role-based access control preventing access of sensitive and confidential data to non-privileged users. Moving to a market with ambiguous weak authentication, lack of fine grained control, improper session control and insufficient logging might not seem like a probable risk until you’re attacked.

Not Incorporating Vulnerability Testing Throughout the Development Lifecycle

Security threats are evolving faster than anyone can keep track of. The Open Web Application Security Project (OWASP), a community of application developers and security professionals, identifies the top 10 security risks each application team must mitigate. This includes risks across injection, data exposure, misconfiguration, security deserialization and so on. Development teams should incorporate vulnerability assessment as a continuous process and not leave it at the end of the deployment cycle.

Automating Security with Development Platforms

Integrating security into your application development process does not have to slow you down. By utilizing key technologies such as a low-code platform, you can accelerate development and enable security procedures at the same time.

While promising accelerated development, what an ideal low-code application development platform offers is a visual development environment and code-customization with two-way workplace sync with IDEs. It also enables autogeneration of code, ensures extensibility and reuse with prefabs, and allows for full integration with CI/CD pipelines.

One of the important features of a low-code platform is built-in security, one that ensures automation of the development of application-level security features. A perfect platform provides a configuration for prevention of security vulnerabilities such as XSS and CSRF and ensures in-built encryption, robust authentication and authorization systems, along with enterprise-grade auditability and traceability.

While speed may be the name of the game, rolling out your applications without considering security would have little positive impact if they fail to function and are not secure. One of the best ways to integrate security across your application development lifecycle is to leverage the benefits of low-code platforms that are designed for professional development, those that have built-in, application-level security features. While your application development plans may be time-critical, security cannot be an afterthought, because sacrificing security for speed may make it longer for you to mitigate the risks than achieve your application development goals.

May 7, 2020
Securing Internet-Facing Portals

Against the backdrop of the current pandemic, barely a day goes by without another portal or web application being launched to help citizens and customers interact with governments and corporations. Bringing these applications to market quickly, and ensuring they can’t compromise the security of the organization, requires DevOps to embrace news techniques and technologies. So, how best can DevOps ensure these applications don’t become a backdoor for the bad guys?

Additional Defensive Techniques

In the OWASP Top Ten list of vulnerabilities in Web Applications, ensuring uploaded documents and images are threat-free doesn’t factor. Yet, these can be the Achilles Heel of any internet-facing portal or application.

The primary vehicle for smuggling malware into an organization is via documents and images. These are routinely embedded with malware, some basic, some extremely sophisticated, targeting the user or employee who eventually uploads the document. Alternatively, the concealed malware can attack the portal itself, for example, via a malformed document.

This malware is sufficiently new and well-concealed that it repeatedly evades detection-based cyber defences and even modern AI technologies. Ensuring that what arrives via the portal is threat-free means finding additional defensive techniques that increase the security without slowing down the application.

Best Practice

The UK’s NCSC has published a set of essential guidelines for anyone charged with the security of an application that must accept documents and images from the internet. In the NCSC “Pattern: For Safely Importing Data,” the organization describes a set of best practice guidelines for accepting documents from untrusted sources and recommends an approach called document transformation to ensure imported documents are threat-free.

Transformation is a mechanism whereby untrusted documents and images have the essential business information extracted from them. The originals are then discarded–along with any embedded threats. The business information is then verified and brand-new documents are then created and formatted to match the originals.

Figure 1: Transformation engine.

Once documents have been through the transformation engine they are completely safe and can be used without any further security measures.

“Baked-in” Security Controls

For the AppSec manager, transformation is a great approach to promote across DevOps teams. It can be accessed via cloud APIs and it adds an additional layer of security–conformant with security best practices–that helps ensure web applications and portals don’t become a backdoor for malware infiltration.

Figure 2: Uploading a Document via an API.

Developers need a choice of transformation APIs, depending on the nature of the particular application. For example, some applications will require a simple upload/download API to transform a file, while other applications will need APIs capable of handling more complex tasks, such as event-driven workflows or moving files between different storage buckets.

Figure 3: AWS Flow Using S3 API.

Head Start

The demand for web applications to accept uploaded documents into portals is only going to increase, and with it the risk of potential for compromise from concealed malware. The good news is that any DevSecOps professional building a web application or portal that must accept documents and images from the internet, already has a head start when it comes to building securely if they are using a serverless architecture.

From a security perspective, the alternative to serverless architectures, machine images in the cloud, have the associated risk that if, for example, malware succeeds in compromising the machine, it remains compromised thereafter. With a serverless, cloud native architecture, there is no residual machine and, therefore, little residual risk.

Another key point in favor of building on a serverless cloud-native computing model is that it devolves the responsibility of patching to the service provider. It is widely understood that unpatched systems are one of the main causes of cybersecurity breaches. Serverless architectures enable the developer to shift operational responsibilities and routine security tasks, such as patching, maintenance and upgrades, to their service provider.

The current pandemic has turbo-charged the demand for internet-facing portals and with it the risk of malware infiltration via uploaded documents and images. For developers, that means finding new defensive techniques like transformation that can be quickly and easily baked into the code to ensure uploads are threat-free.

May 4, 2020
Continuous Security Through Developer Empowerment

Every organization is embracing DevOps to one degree or another. The business impact of shipping software quickly and adapting to market needs is so immense that it has become a requirement—you’re either heading toward DevOps or heading toward bankruptcy. Yet, while our need for speed has increased, so has our need for security—and combining both is far from an easy task.

The key to achieve the DevOps velocity is developer autonomy. Developers and their surrounding application teams need to make daily decisions about what to build and how to build it, and they need to do them on their own. Bottlenecks appear when teams are required to get external approval, slowing down the process and eliminating the dev team’s sense of ownership. The resulting effects are subpar outcomes in applications and attrition of top performing developers.

Yet, security practices, unfortunately, often depend on such reviews. Security audits and reviews are the bread and butter of most security organizations, requiring experts to determine if a decision is secure or not. For security to work at the speed of development, this practice has to change and give developers the power to make security decisions. The only alternative is insecure software and deceleration of software version development.

How can we achieve such developer empowerment for continuous secure software development? Let’s review some key practices, and look at ops practices for inspiration.

Mindset Shift: From Super-Hero Operators to Multiplier Engineers

Site reliability engineering (SRE) teams hold the same responsibility for a service’s uptime as the sysadmins that preceded them. The change in the role came from how they achieved this resilience. SREs don’t handle most incidents, nor do they review all code that affects reliability. Instead, they engineer the tools to empower developers to handle oncall and build operable software the right way. An SRE should only be pulled in for the extreme cases, be it an incident or architecture review.

Security teams must operate in the same manner. Their job must be tactical, working to reduce their involvement in the process and giving more responsibility to the developers. Cases will arise where their expertise is needed, but general inquiries should be kept to a minimum.

Tooling Change: From Security Tools to Developer Tools

Before DevOps kicked in, app performance monitoring (APM) was owned by IT, who used synthetic measurements from many points around the world to assess and monitor how performant an application was. These solutions were powerful, but their developer experience was horrible. They were expensive, which limited tests developers could run. They excelled in explaining the state through aggregating tests, but offered little value to a developer trying to troubleshoot a performance problem. As a result, developers rarely used them.

Then, New Relic came on the scene, introducing a different approach to APM. Their tools were free or cheap to start with, making it accessible to all dev teams. They used instrumentation to offer rich results in developer terms (call stacks, lines of code), making them better for fixing problems. This new approach revolutionized the APM industry, embedded performance monitoring into dev practices and made the web faster.

The same needs to happen for application security. If developers are the ones making impactful security decisions, then the most important users of security tools are no longer security folks—but rather developers themselves. Security tools should therefore focus on achieving developer adoption first and foremost, even when it comes at the expense of more effort by the security person involved.

Governance Change: From Blocking to Monitoring

One of my favourite DevOps adages is, “If it moves, measure it. If it doesn’t move, measure it in case it moves”. It embodies just how critical it is to successfully monitor your running application. While CI/CD pipelines help you get software to production, monitoring gives you the confidence to do it at speed. You don’t need to worry so much about shipping a bug when you’re confident you’ll find out about it quickly and revert or roll out a solution.

Security needs to embrace this approach. Finding out a security vulnerability has just been deployed and acting on it is almost as good as blocking it just before it was deployed—and far less disruptive. But to embrace this, you’ll need to invest in monitoring.

Developers are the first step in the application process. It makes sense that they are also the engineers of security solutions. Empowering developers to make security-first decisions allows IT teams and security professionals to address different parts of the business, saves time in the development process and ultimately creates stronger applications and outcomes.

April 28, 2020
HashiCorp Strengthens Vault Secrets Management

HashiCorp has released an update to its HashiCorp Vault platform for managing secrets and encrypting data that now includes an internal storage option that eliminates the need to manage a separate storage backend.

Version 1.4 of Vault also adds an OpenLDAP Secrets Engine, which automates the management of static entities within OpenLDAP directories, and the ability to authenticate users and applications using the Kerberos authentication protocol.

HashiCorp has also updated the enterprise edition of Vault to add support for a Transform Secrets Engine that can be used to secure data that reside outside of Vault, such as credit card numbers, by applying tokenization techniques to mask data, as well as a Vault Helm Chart tool that makes it easier to deploy Vault on Kubernetes clusters to the enterprise edition of the tool.

Finally, the enterprise edition of Vault adds improved disaster recovery capabilities and support for NetApp enterprise key management to more easily manage encrypted data.

Chris Kent, director of product marketing for HashiCorp, said thanks to the increased focus on data privacy there is a greater appreciation for the need to maintain application secrets in a platform that resides outside of the core application. Regulations such as the General Data Protection Rule (GDPR) enacted by The European Union and the California Consumer Privacy Act (CCPA) penalize companies for losing control over credentials and data. As a result, more organizations are looking for a way to better manage application secrets, noted Kent.

At the same time, cybercriminals are becoming more adept at discovering the credentials of end users that developers sometimes inadvertently leave accessible within their applications, he noted. Vault provides a way to manage and maintain application secrets outside of the application in a way that serves to significantly enhance overall application security.

As developers and cybersecurity teams collaborate more closely as part of any effort to embrace best DevSecOps processes, it’s becoming apparent that a lot more attention must be paid to how application secrets are managed. In fact, arguably one of the biggest impediments to improving the overall security of applications is the way developers have historically managed application secrets. It’s not uncommon for cybercriminals to compromise an application in a way that gives them access to thousands of individual user names and their associated passwords, many of which unfortunately are reused both inside and outside of the extended enterprise. The challenge at this point is not so much making the tools available to manage application secrets as much as it is changing the processes and culture within organizations that are just now starting to embrace DevSecOps.

In general, as organizations become more proficient at managing application secrets the more secure application environments should become. Of course, secrets management is only one aspect of application security. However, the absence of an effective strategy for managing application secrets can prove catastrophic. By the time most IT organizations realize their application secrets have been compromised, it’s usually far too late to undo the damage.

— Mike Vizard

April 8, 2020