devopsy.kinsta.cloud

Category: DevSecOps

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
WordPress Hacks: Best Ways to Protect WordPress from Hacking
When it comes to website security, even an iota of prevention is really worth a large pool of measures to restore a website from its affected state. WordPress websites are most vulnerable to security attacks from sophisticated hackers as well as the bots that are capable of exploiting security vulnerabilities. These security vulnerabilities range from weak passwords, outdated themes and plugins, and poor-quality web hosting.

But, there are several time-tested measures that can prevent such security compromises and risks and keep a website performing and secure.

Make Use of Strong Passwords

Weak passwords often cause security risks for websites. You can prevent such risks by using strong passwords and for this, you can use tracking tools such as 1Password that can track all the passwords and prevent you from using the same password on all your internet accounts. The tool also prevents you from using easy and easily rememberable passwords. Thanks to the tool you can only use unmemorable, long, difficult passwords.

Using this tool you can easily test the strength of the existing passwords and can create passwords that are long, complex and not easy to guess. The tool helps you maintain all your web accounts with strong passwords.

Updating WordPress Core, Themes and Plugins

Most updates of the WordPress core, or the themes and plugins, come to mitigate the security loopholes and risks. This is why making updates once a month is far from enough. Whenever a vulnerability will surface, your non-updated website can be the first victim of the security risk. This is why one must update as soon as there is an available update. For all the plugins that don’t come with important features and functions, one can use a Shield WordPress Security plugin to auto-update.

Insist on WordPress Hardening

There are several WordPress hardening methods that can easily prevent hacking from taking place. Let’s have a quick look at these hardening methods.
- Add extra allow/deny rules through your .htaccess file.
- Keep login URLs restricted to specific IP range(s).
- Safeguard your wp-config file.
- Prevent image hotlinking and mobile directory browsing.
- Do not use public WiFi or VPN to log in to the website.
- Remove unused WordPress plugins and files.
- Keep the server clean.
Prevent a WordPress Hack with a Website Firewall

A vast majority of WordPress websites are frequently hacked as they are more vulnerable to security risks than other CMS platforms. A common issue that security experts stumble upon often is that WordPress version update is often not possible, thanks to the incapabilities of plugins or themes. This is when a WordPress website can easily become vulnerable to hacks.

For such cases, enabling a WordPress firewall is strongly recommended to provide security patches for your website. A Web Application Firewall (WAF), when enabled, can take on such security risks. A WAF basically works like a pass for your website visitor traffic, and effectively filters out bad requests comprising hack attempts, exploits, DoS attacks and many more.

A WordPress firewall does the following things to strengthen WordPress security:
- Prevents all future hacking attempts by detecting and thwarting all hacking methods and behaviors, thus keeping your WordPress website protected against malicious attacks.
- The firewall provides a virtual security update for your WordPress website software, even when the website doesn’t have any new security updates.
- A WordPress firewall also blocks brute force attacks or any unwanted visitors from accessing the wp-admin or wp-login page and makes use of brute force automation to detect your password.
- It deals with Distributed Denial of Service (DDoS) attacks that basically try to overload a web server or the resources of an application with too many requests. By blocking DDoS attacks, a WAF ensures constant accessibility and performance of a WordPress website in all circumstances.
- A WordPress firewall helps boost WordPress performance by storing website caches and keeping bounce rate lower. This also ensures optimum website engagement, business conversions and steady search engine ranking.
- The cloud-based WordPress firewall solutions, besides preventing attacks, also boost WordPress website speed by using a Content Delivery Network (CDN).
Make Sure You Have an SSL Certificate Installed

This is a basic and very important security measure for most websites. It safeguards data by encrypting the data you and users use and transfer via a website. For example, when one submits a contact form or uses login in web pages, the data that is transferred remains encrypted. With SSL installed on a website, secure login can be ensured even while traveling. While some hosts and hosting plans provide this for free, with some you need to use a separate SSL plugin for the purpose.

Avail Better Web Hosting

Choosing good hosting companies can also be crucial for your WordPress security. Some hosting service providers such as WP Engine, Kinsta, Site Ground and a few others are great for WordPress security. These service providers take care of routine security scans and provide cleaning of hacked websites for free. Apart from performance, one should also consider security aspects for website hosting.

Taking Backup of Your Site

Though taking regular backups may not always be effective for preventing a WordPress hack, they can sometimes play a great role in disaster recovery. It is particularly useful in preventing a website database from damages due to malicious attacks.

Continuous Website Monitoring

Finally, continuous monitoring of websites can help greatly in tracking and mitigating security risks of all types. Setting Google Search Console alert is important concerning all issues on your website. Apart from that, you should monitor the error logs on your website through the cPanel File Manager or FTP (SFTP). You should also see the Raw Access Logs on the server to keep track of the users accessing website files on the site. You should also use a plugin called Shield WordPress Security plugin and use its Audit Trail feature to keep track of all the file changes and website accessibility issues.

Conclusion

All the above-mentioned ways are time tested as successful to prevent security attacks and keep security vulnerabilities at check. These measures, besides a meticulous choice of plugins and themes, can help a WordPress website perform well and remain secure.
May 6, 2020
Your Applications Are the Weakest Security Link

Amazon, Microsoft and Google have much bigger security budgets than you do. They have hundreds of people all over the world ensuring that their infrastructure is secure. Their teams are constantly reviewing their code, looking for flaws, vulnerabilities and potential exploits. They monitor hacking forums and run attractive bug-bounty programs in order to remain proactive.

Only a few years ago, kernel errors were prevalent. Now, Microsoft’s and Linux’ teams have nearly eliminated kernel vulnerabilities. For example, according to the CVE database, in 2017 Linux kernel had 169 code execution vulnerabilities, in 2018 only three and in 2019 just five.

When it comes to the cloud platforms, the cloud providers indeed take responsibility for security of the cloud, while the customers remain responsible for security in the cloud–which is where the danger lasts.

Solution architectures are distributed across public cloud and legacy on-prem environments. They contain the customer’s own software as well as open source and third-party products, over which the customer has no control. Proliferation of microservices significantly increases the amount of network interfaces. Growing release velocity leaves no time to identify and address potential security problems and configuration oversights.

While the operating systems and critical infrastructure software are improving, the number of vulnerabilities in application software are growing quite significantly. The ability to alter existing applications or inject additional code allows attackers to turn legitimate software into malicious ones. This kind of vulnerabilities is listed in the “code execution” category, which happens to be the biggest group in the CVE database.

Patching known vulnerabilities takes more than 50 days on average, while attackers need just a few minutes to utilize them. On top of this, there is a huge amount of unknown/unpublished zero-day vulnerabilities, frequently used by commercial attackers who pay for them and keep them to themselves.

In the well-known Equifax data breach, malicious software infiltrated a legitimate web server using an Apache Struts vulnerability that allowed arbitrary code insertion. Since this attack occurred in 2017, the CVE database shows that Apache Struts has had at least five similar types of vulnerabilities.

Basically, customer applications are and will always be the weakest and the most exploitable software. How do we protect them?

Code execution vulnerabilities are exploited while the software is running. Some of the exploits do not leave any file system footprint at all—fileless malware. The exploit may happen days, or even months, into the execution session. The only reliable way to identify a break-in is to verify the software integrity in the same memory where the code is running throughout the entire execution session. Any change to the code or an addition of the unsigned code will compromise its integrity and therefore will be identified.

Traditional, file-based, signature mechanisms will not help here, because the executable files are changed when they are loaded into the memory; therefore, it must be a special algorithm sufficiently robust to protect itself and the application software.

Cryptographic signature uniquely identifies software just like human DNA identifies a person. This mechanism can be further used to provide applications with proper authorizations such as communication and information access. This will ensure that only applications with the right “DNA” can communicate with each other and access encrypted information, which is the ultimate Zero-Trust paradigm.

May 5, 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
One Identity Allies With HashiCorp to Advance DevSecOps

One Identity, a provider of identity management software, has aligned with HashiCorp to make it easier for DevOps teams to implement best DevSecOps practices.

Tyler Reese, a senior product manager for One Identity, said via a plugin for HashiCorp Vault developers can now securely manage, monitor, record and audit privileged and administrative access to their vaulted tokens, passwords, certificates, application programming interface (API) keys and other secrets residing in the Safeguard privileged access management (PAM) platform from One Identity.

The goal is to make it easier for developers to securely access credentials stored within Safeguard without having to provide access to every credential used to access, for example, a packaged application that a developer is trying to provide access to via a custom application or vice versa, he said.

The two companies are trying to bridge the divide between end user credentials managed by IT teams that have control over access to packaged applications and the way DevOps teams manage secrets within their custom applications, said Reese. DevOps teams increasingly need to integrate custom applications with packaged applications. The challenge organizations face is finding a way to securely provide that access in a way that doesn’t require internal IT teams to be overly involved in the application development process, he noted, adding by integrating with HashiCorp Vault, all the friction is taken out of the process.

Based on a transparent protocol proxy software that inspects protocol traffic at the application level, Safeguard rejects traffic that violates policies defined by the internal IT team. That approach prevents unauthorized and unfettered access to data. IT teams can also monitor privileged sessions in real-time with the ability to execute various actions, such as terminating a session if unusual or unwanted behavior is detected. Safeguard also enables IT teams to rotate privileged access passwords to comply with a wide range of regulations, said Reese.

As developers embrace DevSecOps they need to find a way to dovetail their efforts with existing password management processes. For the most part, DevSecOps remains aspirational within most organizations. There is general agreement that more responsibility for security should shift left toward developers. However, most organizations are still a long way from putting the tools in the hands of developers who need to extend existing DevOps workflows. In the absence of those processes and tools, DevSecOps often winds up being little more than a sermon that IT leaders give to development teams.

On the plus side, the rate at which cybersecurity tools that are integrated with the continuous integration/continuous delivery (CI/CD) platforms on which DevOps processes depend is steadily increasing. As that trend continues to gain momentum, the relationship between developers and cybersecurity teams will evolve. Cybersecurity teams will continue to define controls and verify that they have been implemented. Developers will be held accountable for implementing those controls as part of the overall quality assurance process. The challenge now is getting everyone inside behind that cultural transition in advance of the tools that will be available soon.

April 30, 2020
Why You Can’t Have DevOps Without Test Automation

The rapid adoption of digital technologies by enterprises to stay nimble, competitive and quality-driven has given digital transformation wide currency. The process facilitates decision-making and allows organizations to innovate, accelerate the time to market and be responsive to customer needs.

The world of today is for those enterprises that can quickly turn an idea into a consumer product or service, absorb feedback from the market and customers to refine the product/service and relaunch it. This is where DevOps can help such organizations in terms of offering continuous development, innovation, integration and deployment.

Fixing Glitches with DevOps Testing Strategy

To stay on the right side of customer preference, enterprises must roll out software updates on a trot, which is not easy by any stretch of imagination. This is because every update needs to be tested across devices, operating platforms, frameworks, geographies and networks. If the DevOps approach is not right in executing the process of development, testing and deployment, the inherent glitches can prove to be costly. In many cases, in a bid to be ahead of the curve, enterprises do not give testing its due.

In other words, products or their updates are often launched without letting them pass through a stringent QA pipeline. The consequences of such quick deployment without adequate testing may manifest themselves in various ways. These may include the quality of product taking a beating, regulatory bodies subjecting such organizations to censure and penalties, and customers taking a flight to the competitors. With business reputation at stake, enterprises are well-advised to follow a strong DevOps approach and identify/fix glitches quickly in the pipeline.

DevOps and Test Automation

When it comes to DevOps specialists discussing key elements that go into a continuous integration (CI) or continuous delivery (CD) pipeline, they mostly talk about code repositories or CI servers. Interestingly, DevOps test automation finds less mention in the rarefied circles where strategies are planned. This is despite the DevOps test automation being considered an integral part or medium to achieve outcomes like CI and CD.

DevOps specialists mostly focus on aspects such as integration and deployment of the software, thereby giving test automation a miss. This can be self-defeating and invariably goes against the grain of DevOps philosophy where QA forms an integral part along with development and operations. Does this mean these specialists are more tuned into the manual testing aspect while leaving test automation altogether? The probable answer would be the ingrained belief in some DevOps experts about the efficacy of manual testing. This would not have raised any hackles until the advent of continuous delivery chains.

Why Test Automation for DevOps?

The two outcomes of DevOps, CI and CD, mean the development pipeline should deliver quality products quickly and consistently. Besides, the products should be upgraded periodically based on market feedback. This means products should be tested for glitches early in the SDLC to save cost and time. What better way to achieve the same than by implementing test automation in DevOps QA.

Faster test outcomes: Test automation can be implemented by writing a test script on a tool. The code in development is put through that script and checked for expected outcomes. Any deviation is noted and investigated for possible errors. This is way faster than manual testing, where QA specialists find repetitive testing frustrating and have a tendency to miss errors.

Consistent results: Consistency in QA means the software behaves on expected lines throughout the delivery pipeline. Test automation can validate the code for variables at different stages and mitigate the chances of human errors.

Ease with regression testing: When a major update is implemented, certain types of tests, such as usability testing, are performed manually. However, when there are more variables and the software needs to be checked across devices, operating systems, browsers, geographies and networks, then automatic testing takes the cake. It can work non-stop and check for deviations or non-compliance.

Human resources utilization: During manual testing, scarce human testers are deployed in tasks that require constant attention. Further, to avoid boredom arising out of conducting repeated testing, QA testers can give certain tests a miss. Imagine the type or number of glitches escaping the test dragnet and later ruining the user experience. However, with test automation, repetitive testing can go unhindered wherein scarce human resources can be deployed for better activities.

Conclusion

In today’s age of fast software releases, quality can be ensured through a smooth DevOps-led pipeline ensuring CI and CD. However, achieving consistency in testing and pre-empting issues like cybercrime are underpinned on implementing DevSecOps and enabling a culture of quality control at every step of the way.

April 30, 2020
Accurics Makes Infrastructure as Code More Secure

Fresh off raising $5 million in funding, Accurics today launched a platform that analyzes the code employed to manage infrastructure as code for vulnerabilities as well as indicators of drift to create a threat model for cloud application workloads and then, if necessary, automatically roll back cloud settings to their last known approved state.

Accurics CEO Sachin Aggarwal said rather than simply focusing on cloud infrastructure, the startup company’s platform analyzes vulnerability feeds, identity access management (IAM) privileges and other data to detect potential cloud security issues. That analysis can then be shared with third-party security tools to automate remediation, he said.

Once the model is constructed, Accurics then monitors the application workload for changes that introduce risks and generates a topology for each workload in real-time to identify any potential indicators of drift away from the initial deployment settings. If the drift is due to a legitimate change, the code can be updated. If it introduces risks, IT teams can roll their code back to the last known secure posture using a “time machine” capability that Accurics has baked into its platform, he said.

The Accurics platform takes a different approach to cybersecurity—rather than focusing solely on application programming interfaces (APIs) exposed by cloud infrastructure providers, it analyzes everything from the Terraform code used to programmatically install workloads to the container and serverless computing frameworks employed. In the future, Aggarwal said Accurics plans to add integrations with other infrastructure commonly employed in cloud environments, including Jenkins, Bitbucket and GitLab continuous integration/continuous delivery (CI/CD) platforms.

That analysis surfaces violations of common compliance and cybersecurity practices based on Security Operation Center (SOC) 2, General Data Protection Rule (GDPR), Payment Card Industry (PCI), Healthcare Information Portability and Accountability (HIPAA), International Organization of Standardization (ISO), Center for Internet Security (CIS) Benchmark, Amazon Web Services (AWS) Best Practices and the AWS well-architected framework.

Aggarwal said Accurics advances DevSecOps by making it possible for organizations to continuously assess changes within their cloud application environments. Most of the issues involving cloud security today can be traced back to errors made while using tools to programmatically provision cloud infrastructure. The Accurics platform helps developers and cybersecurity teams to collaboratively discover those issues, he noted, adding the overarching goal is to enable both teams to reduce risks by eliminating the most common mistakes that are made in cloud computing environments.

As the relationship between DevOps and cybersecurity teams continues to evolve, it’s become apparent the first issue most organizations need to address when it comes to cloud security is visibility. Most IT teams are concerned about cloud security not because the platforms are less secure than on-premises infrastructure. In general, cloud infrastructure is more secure. However, because of a lack of visibility, it’s not as easy for cybersecurity teams to discover when misconfigurations create a known vulnerability. If that issue gets resolved, much of the resistance to cloud computing generated by security concerns will fade away.

April 28, 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
Enterprise Inertia Slowing Down DevSecOps Integration

DevSecOps has become an increasingly popular topic as enterprises grapple with the continuing challenge of improving their cybersecurity infrastructure. As the first quarter of 2020 has come to a close, are we making significant progress in fully integrating the development, operations and security functions in the enterprise?

The term “DevOps” was first used in 2009 by an IT consultant, Patrick Debois. Little more than a decade later, the IT industry is evolving to DevSecOps in response to the global cybersecurity threat and the realization that a more concerted effort is needed to effectively mitigate risk.

One of the challenges is that DevOps itself is still not fully utilized in many enterprises, making those organizations more reluctant to embrace the idea of adding tighter integration with security teams and frameworks. Anyone who has worked in an organization knows implementing a cultural shift is difficult at best and not an overnight success. Moving from DevOps to DevSecOps does require such a shift.

From Inertia to Integration

The Oracle Java 8 end-of-life story is a great illustration of the need to better integrate security into development and operations. Java applications traditionally were developed and delivered, and the inevitable security updates became the responsibility of the operations team to update the Java Runtime Environment (JRE) on each system that would utilize the application. This inevitably became a struggle of compatibility issues that resulted in exceptions versus resolving the security issues by updating Java.

Java 10 resolves this struggle by creating a more symbiotic experience where the runtime components are baked right into the Java application as it is built. With this change, the dev team needs to take ownership of regular updates to the application to resolve security vulnerabilities, but this shift is slow in coming. Java 8 applications are still a critical part of many operations, even after the end of life of version 8, and companies now turn to OpenJDK and Corretto Java to continue in the legacy model.

This is where inertia comes in. Enterprises stick to legacy systems, such as the Java 8 applications, and continue the cycle of compatibility issues preventing updates required to resolve security vulnerabilities. They have little or no attention from busy security staff, which long ago moved on to critical projects like protecting against the next WannaCry.

Better integration–putting the Sec in DevSecOps more front and center–can be done.

Here are some considerations to move from inertia to integration.

Take Charge

The concepts of ownership and responsibility need to change. A development team that has created a specific product needs to be responsible for taking care of future application needs, such as patching updates. The old-fashioned “We developed it; now we throw it over the wall to operations” doesn’t work in an integrated environment. The team needs to continue responsibility into the operation phase. This ends the volleying back and forth on who “owns” updates, and makes bugs, fixes and patching the DevSecOps team’s responsibility.

Get Your Track Shoes on

Thanks to the plentiful options technology offers, enterprises are using varied development tools, browsers and vulnerability scans. This adds up to challenges since traditional patching is no longer always possible. At the same time, failure to execute updates in real time leaves the enterprise vulnerable to threats. For example, Microsoft introduced the new Edge Chromium edition which utilizes Google’s Chromium open source framework. Google had three Chrome releases between this year’s regular January and February Patch Tuesday events. This meant Microsoft had to integrate Chromium updates in real time or delay resolution to critical vulnerabilities for its customers. As another example, if an enterprise has an internal browser that used Chromium, the same updates have to be pushed out to protect users from threats.

Think Totality of a Fix

The best way to achieve integration is to ensure security is baked in as part of the development and operations process from the beginning. Before a new product/application is launched, a united DevSecOps team will be aware of all the components in that product, all the vendors who will have updates related to those components and the expected cadence of these updates. For enterprises updating a web or SaaS-based application, updates should be doable fairly quickly.

Make Security First

Time-to-market pressures abound but the strategic DevSecOps professionals are placing risk mitigation before operational impact. They are doing this in a landscape in which cyber hygiene continues to be an issue. Legacy systems are not being patched correctly; updates are being done too late, or not at all. To counter this, enterprises need to adopt a security first principle and improve the timeliness and thoroughness of patching and updates.

Know Your Vendors

A must-do is for DevSecOps to fully investigate what patching/updates a particular third-party vendor provides, what their release cadence is and what risk exposure it may present by not covering certain releases/companies. As part of this scrutiny, discern which vendors are responsive to security risks and which are not. With so many companies–Microsoft, Oracle, et al.–executing varied release schedules, adding automation into DevSecOps can further ensure updates are done in real time and cyber hygiene can be improved.

Fulfilling the DevSecOps Promise

DevSecOps can begin to reach its potential by paying attention to the people factor and using technology as a support rather than another headache. Whether an employee is in development, operations or security, they are working for the same organization.

By introducing more automation into the process, gaining a clearer picture of all relevant components and the third-party vendor release cadence, and making security a participant at the beginning of new product development, smoother updates, better security and a productive culture will result.

April 22, 2020