devopsy.kinsta.cloud

Category: DevSecOps

  • Top iOS Security Gotchas

    Top iOS Security Gotchas

    Ensuring the security of user data within your app is critical to building trust in your business and contributing to the online safety of customers.

    Here’s a list of the top 10 essential security mechanisms that Apple offers to up the security posture of your iOS applications. Adopting these technologies and APIs within your products is an effective step toward writing more secure applications, giving you a lower risk of potential data compromise and increased confidence in your security posture.

    Opting Out of System Data Protection

    iOS provides the data protection setting, a robust way to automatically encrypt any files created by your app. This is an important security setting, however, it is turned off by default and many developers never enable it. Leveraging the system’s data protection mechanism is an easy win for increasing the security of user data within your app.

    Transmitting Data Over Insecure Connections

    It’s critical to ensure that any data-in-flight is transmitted over secure connections. By using encrypted HTTPS connections for all apps’ network activities, a wide variety of data-in-flight compromises are mitigated. Additionally, organizations are recommended to leverage SSL pinning for maximum transport-layer security.

    Deserialization Fails

    The default protocol to serialize and deserialize data on iOS, NSCoding, is vulnerable to object substitution attacks, which could potentially allow an attacker to gain remote code execution. Apple offers a near drop-in replacement, NSSecureCoding, which is not vulnerable to this attack. To convert a serialized class to use the NSSecureCoding mechanism, Apple has outlined steps in its documentation. Making the recommended changes allows the system to enforce safe deserialization.

    Opting Out of App Transport Security

    App Transport Security (ATS) is a mechanism provided by Apple to mediate all network connections made by the app and validate that data is being transmitted securely. Opting out of ATS by use of NSAllowArbitraryLoads, or similar exemptions, is an easy way to shoot yourself in the foot and turn off a powerful security mechanism.

    Cryptography API Misuse

    Encrypting user’s data is a no-brainer, but care must be taken to ensure that it’s done in a cryptographically secure way. Some system APIs, such as CommonCrypto, are easy to misuse. This results in the illusion of security, while still allowing an attack vector for user data to be compromised. Be sure to use these APIs with secure options, and never statically embed encryption keys or use an encryption key which is trivially derived.

    Leaking PII to NSUserDefaults

    When handling personally identifiable information (PII) within an app, it can be tempting to store it in a convenient and straightforward way, such as using an NSUserDefaults entry. However, this approach allows any other app on the device to read this potentially sensitive data. Sensitive data, especially identifiable user information, should always be stored in a secure location, such as the device’s keychain, and encrypted when necessary.

    Unsafe Keychain Usage

    While the keychain is the most secure store of data on the Apple device, developers must still take care to ensure they’re using it correctly. It’s possible for developers to save data to the keychain in such a way that the data is always unencrypted and accessible, even when the device is locked and data would otherwise be encrypted. When saving sensitive data to the keychain, ensure that you’re using the strongest possible data-protection settings to maximize security.

    Wherever possible, utilize “kSecAttrAccessibleWhenUnlocked,” the strongest protection class, when saving items in the keychain. This protection class tells the system that data should be encrypted when the user is not actively using your application. If your app needs to access this data while running in the background, you may need to fall back on the “kSecAttrAccessibleAfterFirstUnlock” protection class, which ensures the data is encrypted only until the user has unlocked the device after boot.

    Embedding Vulnerable SDKs

    When an SDK is linked into your application, you’re also implicitly exposing your app to any potential vulnerabilities in the SDK. Compromised SDKs have led to a variety of mobile app attacks, such as a vulnerable AFNetworking version leading to data compromised through a MitM attack. Without a security audit of the SDKs used within the app, developers are blind to the potential vulnerabilities they are introducing.

    Allowing Third Party Keyboards on Sensitive Input Fields

    While installing third party keyboards are useful for user customization, they introduce a new vector for data leakage. This is because the developer of a third party keyboard may be able to extract any information typed on the keyboard. As a result, it’s in the user’s best interest to disable these keyboards when handling sensitive data, such as identifiable information or credit card numbers.

    Leaking PII to Device Logs

    It’s all too easy to leave debug logging, which may include PII, in production builds. Before release, validate that any log statements which might include sensitive data are scrubbed from the code. This might be achieved by way of flags, which only enable these log statements in debug builds. Since logs may be visible to anyone with physical access to the device, it’s paramount to exclude sensitive data from them.

    Since adopting the newest technologies often introduces unforeseen risks, defensive security is a constant endeavor. However, following these top 10 tips will increase your organization’s security posture and reduce vulnerabilities introduced by iOS risks.

  • ClickShare Vulnerabilities May Have Been Patched, But They Mask a Much Bigger Problem

    ClickShare Vulnerabilities May Have Been Patched, But They Mask a Much Bigger Problem

    I think we can all recall a time in recent memory where, in a meeting or at a conference, someone has had issues with presentation technology. It happens so often that there is almost an expectation of a clunky experience, at least initially. It stands as no surprise, then, that ClickShare’s seamless app was immediately popular with end-users. For them, there is nothing easier than using a ClickShare application to push a presentation from their laptop, tablet or smartphone over to a big screen or conference room projector.

    Belgian-based digital projection and imaging technology supplier Barco designed their automation platform to work that way, and big business embraced the concept. FutureSource Consulting puts Barco’s market share in conference technology at 29%, with integration into 40% of all Fortune 1,000 companies.

    When researchers from F-Secure revealed in December that the seemingly innocuous automation platform was riddled with security vulnerabilities, it sent shockwaves through the business community. The uncovered security flaws are critical in nature, and could potentially enable any number of malicious activities. 

    Researchers demonstrated how the vulnerabilities could allow remote users to snoop active presentations, create backdoors into secure networks or even configure a spyware distribution server that would infect every user connecting to a Barco device. Suddenly, companies were faced with the prospect of having serious security problems installed directly inside conference rooms and offices throughout their organization. And because of the nature of the vulnerabilities, a single compromised device could support a network-wide breach.

    “An attacker who successfully compromised one unit gains the ability to decrypt as well as produce valid encrypted images for any unit, whether within one family or across families,” wrote F-Secure officials in their report. “Further, such an attacker may gain access to sensitive data at rest such as the configured WiFi PSK and certificates.”

    To its credit, Barco has been extremely proactive in issuing patches and fixes to the vulnerabilities found within its products. Security vendor Tenable recently released a report showing 15 vulnerabilities across eight presentation tools, including Barco. As of February, only Barco has been active in deploying fixes.

    Although some of the Barco vulnerabilities require hardware changes (and these will be a nightmare to deploy, if a firm acts to this degree to secure them at all), many of them can be corrected with software patches. This gives most enterprise users a seemingly good plan to fix their immediate problems, but they are hardly in the clear now. The problems with Barco are just the tip of the iceberg when it comes to dealing with vulnerabilities in well-known hardware and software products.

    The Root of the Problem

    Now that the immediate issues have been resolved, we need to ask how devices with serious security flaws ended up sitting in thousands of conference rooms worldwide, or why they were so poorly designed and programmed in the first place. It’s not like the F-Secure team was uncovering zero-day or previously unknown vulnerabilities. Ten of the flaws discovered in the Barco products were associated with well-known, common vulnerabilities such as code injection attacks. Most already had Common Vulnerabilities and Exposures (CVE) identifications.

    So how did decades-old CVEs get coded, or even hardwired, into modern presentation tools? The only possible answer is that developers either didn’t know about them, or that security was not made a priority as the Barco devices were being designed. Sadly, this is a common situation, and certainly not exclusive to the Barco teams.

    The best time to fix a vulnerability is while an application is being developed, long before it gets sent out to users. The worst (and most expensive) time is after a product has been deployed, or after it’s been exploited by hackers. This can be a hard lesson, and one that Barco will surely learn as its once-impenetrable market share takes a hit following this security fiasco.

    Shifting security fixes back toward the development process isn’t easy, but is necessary in today’s world where even seemingly simple devices like presentation tools are both surprisingly complex, and also networked into everything else. In this environment, security must become an organizational best practice. It doesn’t matter if a company is programming apps for social media or manufacturing smart toasters, security must be considered in every facet of an organization.

    Prioritizing security best practice and making it a shared responsibility is the goal of the DevSecOps movement, where development, security and operations teams work together to code and deploy secure software and products. It requires as much of a change in culture as anything else. The new mindset needs to be that deploying a working product with security vulnerabilities is just as much a failure as creating one that can’t perform its primary function.

    In a healthy DevSecOps environment, anyone touching software should be security-aware, with developers receiving relevant and frequent training to avoid introducing disastrous bugs into their work. If the teams working for Barco had looked at security as a shared responsibility, there is no way that such a large collection of vulnerabilities, including decades-old CVEs, would have made it into their presentation tools.

    The Safe Path Forward

    Nobody wants to be the next Barco, having to explain why well-known security flaws were deployed through their devices to thousands of enterprise networks around the world. To avoid that fate, companies developing software or smart hardware should immediately prioritize security as both a shared responsibility and an organizational best practice. Creating a healthy DevSecOps program will take time and likely also require a shift in culture, but the results will be more than worth the effort. Robust DevSecOps can crush vulnerabilities long before they cause trouble.

    For companies buying products and software, it’s in their best interest to support firms that have embraced DevSecOps. Doing so will go a long way to making sure that the devices and software obtained from them aren’t ticking time bombs waiting to be exploited by increasingly skilled attackers.

  • 2020 DevSecOps Community Survey: Of 5,045 Developers, Guess How Many Are Happy?

    2020 DevSecOps Community Survey: Of 5,045 Developers, Guess How Many Are Happy?

    We just released the seventh annual DevSecOps Community Survey. We captured the pulse of over 5,000 developers in 102 countries. What we learned about trends in DevSecOps will surprise you—especially the parts about how happiness influences company culture, software security and business competitiveness.

    When we tallied up the results we quickly saw some interesting correlations. Organizations with mature DevSecOps practices innovate faster and produce more secure software. Why? It boils down to having happier developers. Developers in mature practices were 1.5x more likely to say they enjoyed their work. Mature DevSecOps practices are also 1.8x more likely to use automated security tools, which certainly makes developer’s lives easier.

    Here are just a few interesting tidbits we discovered.

    Happiness Influences Culture

    “We’ve always known that DevSecOps is about culture. The 2020 DevSecOps Community Survey, for the first time, reveals clear and convincing empirical evidence that developers are happier and more productive when security is part of the digital transformation and DevOps journey,” said James Wickett, head of research at Verica.io.

    Just like you can’t buy happiness, you can’t buy good culture. You have to cultivate it. Here’s what the survey showed:

    • Developers who received secure coding and programming opportunities are five times more likely to enjoy their work.
    • By contrast, only 19% of unhappy developers get similar training. Unhappy developers say they aren’t satisfied at work and are actively seeking other opportunities. You can see why they are grumpy cats.
    • Happy developers don’t feed off rumors—at least, not for security incidents. Instead, they focus on empirical evidence from better integrated tooling and security teams. Developers working in mature practices are 3.8x less likely to rely on a rumor.

    Happiness Influences Security

    “Mature DevOps practices are constantly testing, deploying and validating that software meets every requirement and allows for fast recovery in the event of a problem. As a result we can easily say, ‘DevSecOps is DevOps done right,’” said Hasan Yasar, technical director and adjunct faculty member at the Software Engineering Institute, Carnegie Mellon University.

    Happy developers build more secure code. Here’s how they do it:

    • Mature DevOps practices are 1.7x more likely to have a complete SBOM (Software Bill of Materials), including dependencies. This makes finding and fixing open source components faster and easier. 
    • Code quality? Check. Happy developers are 3.6x less likely to neglect security. This is because, with proper tools, they can focus their efforts on what is important.
    • Grumpy developers are 2.6x more likely to ignore a security warning compared to happier developers working in more mature DevSecOps practices.

    Happiness Influences Business Outcomes

    “We cannot achieve higher levels of DevOps maturity until we understand how tightly woven people are into the transformation process. More than anything, DevSecOps success is tied to human effort,” said Jayne Groll, CEO of DevOps Institute.

    Businesses depend on secure code built by happy people. Look at these findings:

    • Happy developers are 1.4x more likely to follow their company’s open source governance policy. This is an important part of risk management. Ignoring policy and lessening software supply chain security can have catastrophic business implications.
    • Happy developers are 1.8x more likely to recommend their employer to peers and friends, a real boon for attracting and retaining talent in a competitive environment.
    • Happy developers are 1.7x more likely to get the job done. If productivity is the name of the game (and it often is) then businesses with mature DevSecOps teams outcompete the rest.

    Download the full report here. Also, be sure to register for All Day DevOps | Spring Break on April 17th. I’ll be doing a session that goes over the report in depth and you won’t want to miss it.

    — DJ Schleen

  • HashiCorp Strengthens Vault Secrets Management

    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

  • Palo Alto Networks Advances DevSecOps in the Cloud

    Palo Alto Networks Advances DevSecOps in the Cloud

    Palo Alto Networks has updated its Prisma Cloud to make it easier to embrace best DevSecOps processes while deploying workloads in the cloud.

    New capabilities include the ability to define and apply cybersecurity policies to continuous integration (CI) and continuous delivery (CD) workflows and scanning tools for discovering misconfigurations in cloud infrastructure templates, which is the most common source of cloud security issues.

    Palo Alto Networks has also added the ability to scan virtual machines native to the Amazon Web Services (AWS) before they are deployed as well as an ability to apply policies to workloads running on the AWS Lambda serverless computing framework via a single click. That capability eliminates the need to manually install wrappers in application code running on the AWS Lambda framework.

    John Morello, vice president of Product Management, Container and Serverless Security at Palo Alto Networks, said in the wake of the COVID-19 pandemic, the rate at which workloads will move to the cloud will accelerate. Deploying applications allows organizations to retain a higher level of flexibility, which, given the current uncertainty over how long the COVID-19 pandemic may last or even return once this latest outbreak is contained, means organizations need to be able to manage workloads centrally from any location where their IT staffs are located.

    Of course, cybercriminals that have become especially adept at scanning for cloud misconfigurations realize this as well. As such, many of them will be focusing their future efforts on scanning for vulnerable workloads residing on public clouds, Morello noted.

    A recent analysis of public cloud configurations published by the Unit 42 research arm of Palo Alto Networks found more than 199,000 templates that had medium-to-high vulnerabilities. The most vulnerabilities were discovered in templates created using CloudFormation (42%), Terraform (22%) and YAML for Kubernetes (9%).

    As cloud computing environments become more complex the opportunity only increases for misconfigurations involving, for example, ports left open. IT organizations are increasingly trying to secure a wide range of application workloads running on a mix of public cloud services based on virtual machines, Kubernetes clusters and serverless computing frameworks. Public cloud computing environments assume that responsibility for cybersecurity is shared between the cloud service provider and the IT teams who employ those services. Unfortunately, developers often assume the cloud service provider is assuming more responsibility than they actually do. Most cloud service providers are really only promising to secure the infrastructure they manage. Responsibility for application security remains firmly in the hands of the IT teams deploying cloud applications.

    To rise to that challenge, many organizations have been embracing best DevSecOps processes that shift cybersecurity responsibility further left toward developers. However, to achieve that goal, developers need access to tools that are well-integrated with the CI/CD platforms that DevOps teams rely on to push code out to cloud platforms. Obviously, that shift represents a substantial cultural change that will take time to fully manifest within most organizations. However, no such change is ever likely to be attained without being armed with the tools needed to enhance application security within the context of their existing CI/CD workflows.

    — Mike Vizard

  • Filling the Skills Gap for Effective DevSecOps

    Filling the Skills Gap for Effective DevSecOps

    With the rise of DevSecOps comes a whole new need for training and upskilling. It isn’t a secret that the cybersecurity skills gap will only continue to grow. The security skills gap combined with the rise of DevSecOps has introduced hidden challenges organizations must address.  

    The Rise of DevSecOps 

    While DevOps accelerates agility and scalability of organizations, it may also expand risks of threats—particularly if security is an afterthought in an organization’s cloud strategy. In a recent survey, 52% of companies admitted to scaling back security measures to meet a business deadline or objective. Similarly, 68% said their CEOs demand that DevOps and security teams prioritize accelerating business processes. 

    Even when organizations race to release updates despite security consequences, the threat landscape is becoming more complex, faster and automated. In the third quarter of 2018, FortiGuard Labs noted almost 34,000 new malware variants—a 40% increase over the second quarter and a 126% increase over the first quarter. Cyber criminals now use advanced technologies such as artificial intelligence (AI) and swarm technology—as well as DevOps itself—to create single-use malware that targets a particular organization across several points of the attack surface. 

    Thus, companies have realized that security must be woven into the DevOps approach–hence the birth and rapidly increasing adoption– of DevSecOps.

    The Security Skills Gap

    At the same time that organizations are embracing DevSecOps, the paucity of skilled IT talent persists. A report from 451 Research on the IT skills shortage notes organizations are facing talent gaps across a range of IT specialties, including database administration (31%), general network administration (36%) and server/systems administration (43%). 

    The dearth of seasoned cybersecurity professionals looms even larger, with an estimated skills gap of just under 3 million individuals. Understandably, 53% of respondents to a report from ESG admitted to a significant shortfall of cybersecurity skills at their organization. These figures represent the general cybersecurity personnel needed to support and secure traditional network environments, to say nothing of DevOps.

    Overcoming the Hidden Challenges

    In DevOps, any security implementation that hinders speed will be seen as a threat to their primary objectives. Traditional IT teams and DevOps teams are often at odds here. IT will suggest the use of security tools that DevOps sees as causing bottlenecks, which runs counter to their primary objectives. However, while DevOps may be highly proficient at building applications, they often lack the expertise and skills to do so securely.

    An answer to this challenge is to add a cybersecurity specialist to each DevOps team to create a DevSecOps team. This DevOps security specialist (or team of specialists) can guide application developers through the shared responsibility model, helping them stay on track with both development and security requirements. They’re also there to provide strategies for consistent security policies across and between all their cloud workloads and services, all while protecting the DevOps mission of reliability and high performance.

    With DevSecOps in place, the team can choose, implement and manage tools that will better equip them to meet the goals of speed and security. Take, for instance, the use of security solutions that are offered as a service (SaaS) or web application firewalls, which can auto-scale. That allows publicly facing web apps to grow as needed, without compromising security. The right tools can also be eased into deployment with minimal effort. Some even have built-in functions that cover security during deployment, maintenance, scaling and for all the fine-tuning that needs to take place throughout ongoing use and development.

    Once an organization has augmented DevOps with DevSecOps, teams can integrate security from day one of each new project. DevSecOps team can also develop the necessary cloud security playbooks and ensure that those guidelines are followed. DevSecOps can even directly affect the bottom line when they help prevent violations against regulatory requirements and the fees and penalties that come with them.

    Closing the Gap

    The fact remains, though, that good skills are hard to find. This makes it harder to have a DevSecOps team in place. Applications being built in or migrated to the cloud need to be protected against new threats that propagate across workloads—and from cloud platform misconfigurations at the user interface and application programming interface levels. 

    Addressing this challenge requires a concerted effort on the part of both the private and public sectors to develop just-in-time training and education programs to develop cybersecurity skills that are critical for every organization, and furthermore educate for cloud security and DevSecOps practices. More and more organizations are in need of training programs that focus on the cloud security skills necessary to upskill their current and future workforce.  

    Failure to understand and implement a security strategy can make an organization susceptible to policy and enforcement gaps, as well as risk to business continuity and digital operations, which can determine whether or not your organization is able to thrive in today’s digital landscape.

    Proactive DevSecOps

    As organizations evolve from DevOps to adding a DevSecOps practice, the talent shortage continues to loom large. This shortage could pose significant security risks to your organization. But, you can play an active role in bridging the skills gap by identifying training programs and certifications available for your teams focused on security. Employees completing these trainings and earning relevant certification can then work with IT security and DevOps teams to provide the security that enables the speed you need to remain competitive.

    — Lior Cohen

  • Six Steps Every Business Should Take to Protect Its Data

    Six Steps Every Business Should Take to Protect Its Data

    Data may or may not be the new oil but it is the growth engine of today’s digital age. Data about a company’s customers, products, services and sales is worth a lot to the company itself, of course, but also to its competitors, as well as to business-savvy hackers. This is why every business, regardless of size, needs to protect its data. 

    Once created, data never really dies, and it is used in multiple ways. In fact, the more data is used for making decisions, the more valuable this asset becomes to you and everybody else.  

    Protecting something of such value requires a different strategy–we need to start from the data itself. This may look complex but here is an easy way of thinking about that process.

    What Data Do You Have?

    Knowing what sensitive data your company is generating and storing sounds like a no-brainer, but many businesses don’t have a good handle on the different types of data they create, copy, use or store. You may not realize, but some of your data might include personally identifiable information (PII), healthcare data and financial data. As you are a custodian of such data, this requires special attention not only to protect your users, but also to satisfy compliance regulations. If you do not know your data, you cannot quantify your risk, and hence cannot prioritize your limited resources and time.

    Where Is Your Data?

    If you don’t know where your data is, you cannot protect it. And many times, even IT staff aren’t exactly sure where sensitive data resides. Your data could be in databases, file systems, applications or archives. For a hacker, these are all ripe targets, not to mention the four, eight or more copies of the same data distributed across less protected test, development, disaster recovery and backup systems. In addition, fragments of your sensitive data often get distributed across dozens of interlinked or even disconnected systems. If that sounds odd, think of your own personal information. Some of those bits may sit in email, Word and Excel, along with text messages, sticky notes and notebooks. Now, extrapolate this to a company of thousands of employees, and recognize that hackers need to get access to only one of those sources.

    Who Has Access?

    It is important to understand who your users are, and what access they have. Many companies give too much access to too many people, and worse, they do not know about how many keys have been distributed across the company, and to whom. Instead, companies should limit access to as little data as possible, and assign rights on a strict “need-to-know” basis. The fewer the people with limited access, the lesser the chance that they copy, share or contaminate that data. Even if a hacker were to take over their account, your loss would be limited.

    Who Touched Your Data?

    Understanding where your data is and who can access it is a great starting point, but you need to monitor actual data access to detect anomalies and unauthorized usage. Given that threats and vulnerabilities are always evolving, you may not be able to stop all of them, but detecting intrusion can allow you to intervene and limit the loss. Companies should audit users who log on to their systems, and track what they are doing, especially if they have administrative access to those systems or have broad access to sensitive data. It’s not that you do not trust them, but blind trust without verification can be exploited—especially by hackers masquerading as them.

    Why Keep Doors Open?

    A bank with broken windows or weak locks on side doors invites intruders. It is critical to lock down your systems by reviewing your configuration settings, patching your systems, closing unused services/ports and locking down critical data. Hackers today have sophisticated automated tools that can quickly scan systems for gaps and vulnerabilities. If they are going to map out your IT systems, don’t you want to scan them and fix them before they come probing? The more exploitable the holes in your system, the faster a hacker’s ROI.

    Why Use Real Data?

    It certainly is easy to test applications against real data, but doing so creates copies of data that your organization was already having trouble protecting. One simple way to reduce risk is to use fake-but-real-looking data for testing and development purposes. This means systematically replacing all occurrences of real social security, credit card numbers, email addresses, financial information and health data with unrelated random data. Using fake data not only limits exposure to the testers and developers, but also mitigates damage should someone gain access to the test system.

    Protecting data isn’t just about setting up the firewall or installing anti-virus software on your endpoints. To most adversaries, these are just speed bumps. Protecting data requires starting from the time of creating data, discovering what you have, knowing where it is stored, enforcing access rights and tracking its usage.

    As custodians of the valuable data that never dies, we need to have a strategy around completing these tasks in a scalable and repeatable manner. Status quo is not an option in an age where breaches are the stuff of near-daily headlines.

    We hope you never become a target of any attacks, but in case you do, understanding your sensitive data and being proactive in protecting it can make the difference between a quick recovery and a drawn-out nightmare.

    — Vipin Samar

  • Free Remote Endpoint Protection Solution From Qualys

    Free Remote Endpoint Protection Solution From Qualys

    Qualys today announced it is offering a completely free, 60-day version of its cloud-based remote endpoint protection solution. The product is fully featured, with nothing turned off in the free version. It’s also cloud-based, so there are no worries about hosting the solution. This comes at a perfect time, with so many workers working remotely.

    You can download the free solution at:

    www.qualys.com/forms/remote-endpoint

    According to the Qualys release:

    “The Qualys remote endpoint security solution allows security teams to leverage the lightweight Qualys Cloud Agent to:

    • Complete an up-to-date inventory of all their remote endpoint hardware and the applications they are running
    • Gain a real-time view of all critical vulnerabilities impacting the operating system and applications posing a risk to these devices
    • Remotely patch these systems within hours from the cloud with one click of a mouse without using the limited bandwidth available on VPN gateways
    • Realize visibility in device hygiene by tracking common misconfigurations that leave the endpoints exposed to exploits.”

    devopsy.kinsta.cloud spoke with Qualys President Sumedh Thakar for more information on this new free solution. That conversation can be heard below:

    Here’s a screenshot of the web-based interface of the solution:

    Qualys endpoint screen shot

    What happens after the 60 days you ask?  Qualys did not say definitively what the plan is for that, but I suspect that will depend on what happens with our economy and the work-from-home trends. In the meantime, if you are looking for a remote endpoint solution for the enterprise, this is a great chance to try one free for 60 days.

    — Alan Shimel

  • 42Crunch Extends API Security Alliance With Microsoft

    42Crunch Extends API Security Alliance With Microsoft

    42Crunch this week announced it has extended an existing alliance with Microsoft to now include support for Microsoft Azure Pipelines for its REST API Static Security Testing Tool. Previously, 42Crunch only provided support for the Microsoft Visual Studio integrated development environment (IDE).

    Dmitry Sotnikov, chief product and marketing officer for 42Crunch, said support for the Microsoft IDE assumes that developers will run security tests themselves. By integrating its API security testing tool with the Microsoft continuous integration/continuous delivery (CI/CD) platform, it now becomes possible to make testing APIs for security vulnerabilities part of a DevOps process, he said.

    That approach means organizations don’t have to rely on developers to remember to run a security test on their APIs. Instead, security testing of APIs becomes just another gate in the CI/CD process that gets automatically conducted, he noted.

    The company has already integrated its API security testing tool with other CI/CD platforms at the request of individual customers. 42Crunch will be moving to make those integrations commercially available in the months ahead, said Sotnikov.

    As IT organizations have become more adept at thwarting attacks aimed at end users, cybercriminals are now increasingly focusing their efforts on APIs. Akamai, a provider of content delivery networks, recently reported that from December 2017 through November 2019 it observed 85,422,079,109 credential abuse attacks across its customer base. Nearly 20%, or 16,557,875,875, of those attacks were against hostnames that were clearly identified as API endpoints. Many of those attacks involve, for example, unexpected injections of values to a call made to an API, noted Sotnikov.

    The REST API Static Security Testing Tool can locate API contract files in the repository and run more than 200 security checks based on OpenAPI standard requirements, authentication, authorization and data validation. This makes sure that no new or changed API be deployed in production without meeting those standards.

    Issues discovered are also prioritized by impact and each issue is accompanied by a knowledge base article explaining the issue, its severity, exploit scenario and suggested ways to fix it.

    Sotnikov said the REST API Static Security Testing Tool provides a tangible means for DevOps teams to embrace best DevSecOps processes. Too much of what passes for DevSecOps today amounts to little more than attempting to blame developers for cybersecurity issues, he noted, adding organizations that want to embrace DevSecOps in a meaningful way need to put tools into the hands of DevOps teams that enable them to address vulnerabilities once they are discovered and prioritized.

    It’s also critical to provide those tools within the context of existing DevOps processes; otherwise, developers are likely to resist changes to their existing workflow processes, Sotnikov said.

    It remains to be seen how DevOps and cybersecurity teams will meld their respective cultures to drive DevSecOps. It is likely cybersecurity teams will continue to define controls and discover vulnerabilities. However, as DevOps teams continue to make security a natural extension of the quality assurance process associated with building any application, the number of vulnerabilities being discovered after an application is deployed in production should decline steadily.

    — Mike Vizard

  • The DevOps Sweet Spot: Inserting Security at Pull Requests (Part 2)

    The DevOps Sweet Spot: Inserting Security at Pull Requests (Part 2)

    In part one of this two-part series, I explored how organizations can more effectively automate security quality decisions and discard doing automation for automation’s sake. I shared why security scans need to be faster, more reliable and comprehensive. Only then can security be meaningfully automated into developer workflows without slowing them down.

    But, the other part of this is understanding where these security scans should take place throughout the SDLC. Why? Because inserting security too early or too late in development and pre-production can have drastic impacts on remediation efficiency, developer productivity and more. 

    Shifting Security as Far Left as Pull Requests

    Identifying vulnerabilities once they’re in production is the riskiest, as well as the most time-consuming and expensive remediation. Working in pre-production test environments or builds reduces the risk, but not much of the time or efficiency in remediation. Conversely, inserting code analysis into developer IDE’s is too early. While in theory the IDE could be a good place for security feedback, in practice, it slows down the developer’s machine and comes at a huge cost of productivity.

    Instead, commits and pull requests are the ideal place to insert security because it delivers the right vulnerability information to the right developer at the right time. Combine this with integrations into ticketing and other systems and the full developer workflow can be meaningfully automated.

    Simply by getting the right developer, the right vulnerabilities information breaks down one of the biggest challenges in AppSec. Developers typically outnumber AppSec team members by 50-1 or more—hence a security scan that generates 100 vulnerabilities creates a tremendous amount of work for a single AppSec professional. However, assigned to the right developers, at an average of two per person, the challenge immediately becomes more manageable. Still accuracy matters because, while the burden may be spread out, developers triaging false positives is an expensive resource focusing on a low value task.

    Getting developers security feedback at the right time is also vitally important. When developers get immediate security feedback, vulnerabilities become easier to fix because the code is still fresh in their mind. Furthermore, fixing vulnerabilities early has compounding benefits. Since insecure code never goes into production, not only is the attack surface reduced, but additional code that is dependent on the vulnerability never gets written. This minimizes the most expensive and time-consuming security fixes, which require not only fixing the underlying vulnerability, but also rewriting dependent code. Best of all, with immediate, regular, comprehensive and accurate security feedback, developers will ultimately learn and adopt more secure coding practices overtime.

    Lastly, by inserting security at the commit or pull request, security and developers can establish a shared responsibility model on more realistic terms. When security can commit to accuracy and timely KPIs, developers can commit to triaging and fixing vulnerabilities faster. This reduces MTTR, puts a downward trend on defect density and reduces the application’s overall attack surface. It also reflects the realities that AppSec professionals have a limited ability to triage vulnerabilities, because they don’t know the code intimately and that only developers can fix the underlying vulnerabilities.

    By solving the fundamental challenges of speed, accuracy and comprehensiveness to deliver the right vulnerability to the right developer at the right time, security earns the ability to ask more from developers, and CISOs and CTOs can jointly accept responsibility for protecting applications and data.

    The rate at which software is being created and shipped isn’t slowing down, but many organizations have struggled to find where security most effectively fits into this process. By inserting security at the pull request, not only can developers identify and remediate vulnerabilities faster and more accurately, they can better automate security quality decisions. By taking this approach, organizations are fundamentally changing how engineering and security collaborate within enterprises.

    — Chetan Conikee