devopsy.kinsta.cloud

Tag: app security

  • COVID-19, the New Normal and the Indisputable Importance of Mobile App Security

    COVID-19, the New Normal and the Indisputable Importance of Mobile App Security

    As the United States emerges from COVID-19 lockdown, it’s not back to business as usual. COVID-19 remains a very serious risk, and until a vaccine or treatment arrives, we will all need to remain vigilant. Further, it’s also certain that the new normal post-COVID-19 world represents a fundamental transformation in how businesses operate, with mobile business models taking center stage.

    For most businesses, their storefront was their most important asset for awareness and revenue generation prior to the pandemic. Having a good physical location was critical to bringing in foot traffic and allowing customers to easily discover them. In the new normal, however, digital location has become far more important as consumers are increasingly turning to their mobile devices. So, it’s critical for businesses to make apps that are easy to find and use in order to continue generating revenue going forward.

    The combination of the pandemic and growing mobile usage has made developing and updating apps not just a nice-to-have marketing tool, but a necessary task for business survival. An enormous number of previously casual mobile users are now depending on mobile apps for their banking, shopping and other day-to-day transactions. As such, businesses need to redesign their apps to ensure they’re easy and intuitive to use so they don’t lose those potential customers. This requires developers to iterate even faster to deliver an engaging, glitch-free experience.

    Unfortunately, in the mad rush to ship apps as fast as possible, security often gets short shrift in favor of features and functionality. According to the Verizon Mobile Security Index 2020, even before the pandemic hit, 43% of app developers said they knew they were cutting corners on security to “get the job done.” 

    Features Trump Security … Until They Don’t

    Now with business models hinging on mobile, developers can no longer rest on “features first, security later” mentalities. The struggle here is that implementing mobile app security is hard to do. It takes time, often extending the development cycle, and it’s expensive. Even if development teams are committed to implementing security, they may lack the skills to do so — good iOS and Android security engineers are scarce and in high demand.

    Eventually, however, poor security will bring consequences. Cybercriminals operate much like nimble startups, searching for opportunities, creating minimal viable malware and then continually improving it to become more effective. Case in point: the EventBot malware for Android that was discovered in April. It masquerades as a legitimate app, such as a banking app or other popular consumer that, once installed, harvest unprotected data from other apps on a device. EventBot also can intercept text messages (SMS) sent to the device, which enables it to capture the identity verification codes used by multi-factor authentication solutions. With access to these codes and the unprotected user credentials found in the app, hackers can easily launch account takeover attacks on tens of thousands of unsuspecting mobile app users.

    What’s more, the new normal post-COVID-19 world is causing a huge increase in app usage, cybercriminals and hackers believe that the time is ripe to start exploiting known mobile app security flaws. For example, it’s not a secret that most mobile apps lack basic encryption. Similarly, most apps can be tampered with, repackaged and distributed on non-official app stores. With malware like EventBot that can be embedded in popular apps that users already trust, the game for mobile app exploits has been upped dramatically.

    EventBot is just one example of why it’s critical for app developers to encrypt all app data (including the strings, resources and in-app preferences that are stored on the device), obfuscate code and shield apps from tampering and reverse engineering efforts. Doing so will stop EventBot and other potential attacks, and prevent cybercriminals from using apps as Trojans for additional attacks.

    Solutions to the Security Development Challenge 

    If a development team decides the best route is to implement security themselves, they should first make sure they have the appropriate skills in house. If so, a good start is to address each of the OWASP Mobile Top Ten vulnerabilities. 

    Other development teams turn to security software development kits (SDKs), which they will integrate into their apps to provide security. This reduces the scope of the coding but still requires developers to have extensive security experience, and it’s critical to vet SDKs before integrating them, because rogue and vulnerable SDKs are a serious problem in the mobile app industry.

    A final option is security automation through artificial intelligence. It’s fast, taking just minutes to completely secure an app without any coding, and compared to manual coding, it’s inexpensive. But, as you should do anytime you’re outsourcing security, do your due diligence to make sure the platform truly secures the app without introducing additional vulnerabilities.

    The new normal has elevated the importance of mobile apps as the primary way customers interact with businesses, and cybercriminals are taking note. So, in the race to provide an engaging, intuitive experience for customers, don’t neglect their safety. Focusing on features and functionality at the expense of security might pay off in the short-term, but the long-term consequences could be grave. Identify the security development model that will work best for your team, but make sure you implement security quickly. Cybercriminals will not wait for you to prepare before launching new, even more devastating attacks.

  • 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.

  • Better Apps and Better Security When You Shift Left

    Better Apps and Better Security When You Shift Left

    Tens of thousands of people and hundreds of cybersecurity vendors descended on San Francisco at the end of April. While the RSA Conference was the primary draw, there are a number of peripheral events that go on throughout the week as well, such as the Cloud Security Alliance Summit, the CIO/CISO Interchange, BSides San Francisco and the Qualys Security Conference.

    I was able to attend some of the Qualys Security Conference and I had the opportunity to see Alex Mandernack, security solution architect for product management at Qualys, presenting on the need to shift left when it comes to cybersecurity.

    Mandernack outlined some of the issues organizations face today when it comes to security. Migrating to the cloud and embracing DevOps culture means more ephemeral, elastic environments and compressed development time frames. He pointed out that these trends make security more challenging, but also described the opportunity they present to change our approach to streamline and improve security.

    The Traditional Pipeline is Broken

    The traditional model of application development is much more linear. Each app team builds their own image—often in a silo or vacuum disconnected from other teams. Penetration testing is conducted on a sporadic or infrequent basis, and eventually the app is deployed. Vulnerability scans are run on the app in production, and issues or deficiencies are reported back to the developers to address or incorporate into the next build.

    The process is slow and cumbersome. It also has the potential to introduce redundancies that waste resources and make the organization less efficient. As companies embrace DevOps and move to the cloud, the traditional development pipeline simply doesn’t work—especially not for security.

    DevOps, and Cloud, and Containers — Oh My!

    The cloud and DevOps fundamentally change the development lifecycle. Development time frames are compressed, and the process is a self-feeding, iterative circle rather than a repeating linear approach. The traditional approach of identifying and resolving security issues after an application is deployed won’t work in a DevOps environment because by the time issues are identified and fixed, the app itself may have already moved on to the next version.

    Cybersecurity and the development pipeline have enough challenges with the cloud and DevOps, but there is also a newer technology trend that exacerbates the problem—containers. Containers are designed to get code quickly and to operate fast. They are also built for scalability—spawning and spinning down hundreds or thousands of containers constantly to keep pace with demand.

    There is a diverse array of tools and platforms associated with cloud, DevOps and containers. Organizations often employ a complex collection comprised of some combination of AWS, Azure, Docker, Kubernetes, OpenShift and others. The result can quickly become a black hole when it comes to security—which is why it’s important to push security left into the CI/CD pipeline.

    Shift Left to Help Security Teams Do Better

    In a DevOps culture, developers and security teams need to think about security sooner. It’s important to get the security tools into the process earlier. Thankfully, with the DevOps lifecycle and the tools commonly used within a DevOps environment, it can be done.

    For starters, companies should build a golden image. Developers shouldn’t have to patch and update the base operating system before they even start developing. The golden image takes a baseline operating system such as Ubuntu or CentOS, and completely patches and configures it so everyone has a standard, consistent image to develop on.

    With the golden image in place, the next step in shifting security left is to implement testing and scanning in the CI/CD pipeline. Put vulnerability information at the fingertips of developers as they’re developing and implement vulnerability gates in the pipeline to ensure that applications that don’t comply with policies and meet minimum requirements are not allowed to be deployed.

    New Role of the Security Team

    Part of shifting security left includes providing tools that make security self-service for the DevOps team. Automating actions with scripting, APIs and CI plugins ensures that security is simplified and streamlined to provide value for developers.

    In this shift left scenario, the security team has to redefine its role in the process. The security team is still vital, but rather than being the police or a roadblock in the development process, the role of security focuses on verifying and auditing the process. The security framework should have dashboards and live data that enable the security team to monitor activity and identify trends that may need further attention.

    Better Security, Faster

    There is often conflict between developers and security teams, but there doesn’t need to be. Mandernack stressed that developers don’t want to create insecure apps either.

    Shifting security to the left into the CI/CD pipeline streamlines the whole process. Ultimately, the result is higher quality, more secure applications that are developed faster.

    — Tony Bradley

  • What It Really Takes to Build a Reliable App

    What It Really Takes to Build a Reliable App

    What makes an app reliable? If you ask most IT professionals that question, their minds immediately go to uptime. That’s not surprising; after all, it’s fashionable for software and infrastructure vendors these days to boast about how many nines of uptime they guarantee.

    To be sure, uptime is one component of delivering a reliable application experience for developers and end-users. But it’s only one. In order to build reliability into your application patterns, you must think beyond uptime alone.

    Keep reading for an overview of all the factors that go into achieving reliability.

    What Is Reliability?

    A reliable application is one that meets the needs and expectations of everyone it serves. While those needs and expectations will vary from case to case, reliability is characterized by the ability of an app to:

    • Be accessible when needed.
    • Respond within the time frame needed.
    • Be updated or modified as needed.
    • Provide security and privacy to the extent needed.
    • Meet the needs and expectations not just of end-users, but of everyone else who helps create or support the app.

    Maximizing Reliability for Cloud-Native Apps

    Achieving these features for modern, cloud-native applications requires a multi-pronged approach. The following are the core considerations to address in order to build reliability into an app pattern:

    Uptime

    We’ll start with uptime, which is the most obvious aspect of reliability. Uptime refers to the amount of time that your application is available, at least to some extent (as we’ll discuss below, merely being available does not necessarily mean that the app satisfies other requirements of reliability).

    Maximizing uptime typically involves solutions such as distributing workloads across different servers or data centers (so if part of your infrastructure fails, others remain available) and using automated failover to move a workload to new infrastructure if it fails in one location.

    Culture and processes are part of the picture, too, since you need to make sure your team is prepared to respond quickly to any incidents that arise, in order to minimize downtime.

    It’s worth noting, by the way, there can be such a thing as too much uptime. If you reach the point where adding more uptime doesn’t deliver any additional value to your organization, then it’s probably time to stop. Adding another nine to your availability, just because you can, might be a poor use of resources. So, be sure to factor this part of the equation into your uptime calculations and strategy.

    Performance and Efficiency

    In order to meet stakeholder needs and expectations, an application must not only be available, but also able to respond within the time frame required by those stakeholders. A website that is up 100% of the time but takes 20 seconds to load each page is not a very reliable website.

    This is why performance testing and monitoring must be built into your application delivery chain. You should also ensure that you rightsize infrastructure (for example, by choosing the right types of cloud instances) in order to guarantee that your applications have enough resources available to perform adequately. (Of course, this priority must be balanced with cost-control.)

    Accessibility and Usability

    An application that is available all of the time and responds quickly may still fail to meet stakeholder needs if it is difficult to work with due to poor design.

    From an end-user’s perspective, user-experience testing is the most obvious way to help mitigate the risk of poor accessibility or usability within your applications. But keep in mind that you also need to think about usability from the perspective of your own team. Make sure that access-control systems, infrastructure architectures and documentation can be navigated easily. You don’t want an application or a delivery chain that is too complex for your team to be able to support effectively.

    Security and Data Privacy

    A reliable application is a secure application. There are many obvious ways to help secure applications, such as using vulnerability monitoring tools. But remember security is not just about finding vulnerabilities as they arise or deploying certain tools. You must also build security into the design of your infrastructure, processes and culture.

    Backup and Recovery

    You don’t need to be a seasoned IT professional to know that backing up data is important for achieving reliability. When something goes wrong–which it occasionally will, despite your best plans and efforts–having a backup in place often means the difference between experiencing a blip in service and a major catastrophe.

    The thing that can be easier to overlook is the importance of having a disaster recovery plan in place as well as a backup routine. Simply backing up your data isn’t enough; you must also know how you’re going to restore it to new application instances quickly if disaster strikes. If, for example, all of your cloud-based virtual machines go down, what is the exact process you’ll follow for standing them back up? Identifying the steps ahead of time–and, ideally, scripting them so the recovery process can be as automated as possible–is crucial.

    Also important is quantifying how often you need to back up data, which is determined by a metric called Recovery Point Objective (RPO), and how quickly you need to be able to recover it to avoid serious business disruption–determined by Recovery Time Objective (RTO). Along similar lines, error budgets, which define how much time you can tolerate your production systems being down, can help you define the available time monthly for making system improvements.

    Modifiability

    Few apps are deployed and then never modified again. Instead, they must be updated or scaled constantly to meet changing needs and demands. That’s why designing an application pattern that can be easily modified is critical for achieving reliability over the long term.

    In practice, modifiability entails having the right tools (such as automated deployment solutions) and the right processes (such as clear feedback loops between ITOps and developers) in order to decide efficiently what modifications to implement. It might also involve taking advantage of infrastructure technologies (such as containers) that make it easy to update a running application without imposing downtime on users.

    Conclusion

    Reliability is more complex than it may seem. No matter how many nines are included in your SLAs, you are not guaranteeing true reliability unless you also address requirements such as performance, usability and modifiability.

    This sponsored article was written on behalf of Eplexity.

    — Chris Tozzi

  • Three Ways Developers Can Worry Less About Security

    Three Ways Developers Can Worry Less About Security

    Over the past 10 years, developers have risen in organizational importance. They’ve acquired more tools, power, responsibility and autonomy. As part of that evolution, many developers today want to touch all of the layers of code and have their hands in every tool that’s being built. Known as “mechanical sympathy,” developers are taking increased initiative in areas they simply haven’t before–like installing security systems or being in charge of their team’s application security lifecycle.

    While pride of ownership is never a bad thing, in today’s complex IT environments, where organizations are adopting hybrid cloud solutions, microservices and containers–and are required to push applications and software into production as quickly as possible–this simply isn’t scalable. Pursuing mechanical sympathy in this case can be too costly and ultimately become counterproductive–especially when it comes to security, where an attacker only needs to find one vulnerability to gain a foothold in the system.

    Rather than relying on developers to become security experts, organizations should empower them to dig deep on the tasks that matter to them (development) and leverage the expertise of other specialists (security). That way, everyone can focus on their own productivity and deliver the most value to the business.

    Here are three ways developers can let go of their need for mechanical sympathy.

    Consider the Implications of Being Responsible for Security

    Taking on security means abiding by security best practices, like adopting multi-factor authentication and implementing privileged access security for secrets management. None of this is in the typical wheelhouse of the developer, and in fact, developers could actually be increasing risk if they intend on being responsible for security.

    Developers should think of it this way: Imagine something goes wrong with the application you put into production, such as leaking sensitive data based on a mistake in the source code or a design flaw. Do you really want to be the team who’s called? The answer is probably no.

    By focusing on core developer strengths and allowing security teams to handle an organization’s security strategy, developers are able to collectively ship applications that are functionally sound, as well as secure.

    Don’t Solve for Already-Solved Problems

    When it comes to DevOps methodology, there are an increasing number of tools now available that automate time-consuming security tasks–such as automated secrets management, encryption and vaulting solutions–which remove those burdens from developers and allow them to work at true velocity.

    With these tools available, there’s no need to reinvent the wheel. Developers should leverage these assets to their advantage and abstract away complexity to the security team, who should be governing and provisioning security tools so developers can get back to delivering applications to market as efficiently as possible.

    Prioritize the Value Stream

    The aforementioned tools provide a great benefit to developers–freeing them up to focus on more impactful work–but it can be easy for the opposite effect to take hold if developers get mired down in the weeds with them. Instead of trying to specialize in tools such as Kubernetes or OpenShift, which have manufactured obsolescence to begin with, developers should be encouraged to think about the big picture–creating a high-performance, automated pipeline that accelerates software delivery from code to production.

    By focusing on the health of the pipeline, rather than the specific tools within, developers establish a real-time feedback loop that enables them to anticipate the future and see the amazing projects that are truly possible. It positions them as drivers of innovation and increases their sphere of influence across the organization.

    Developers play a critical role in bringing applications and software to market with speed and stability, but when organizations default to letting them own everything from the nuts to bolts, they may end up introducing security issues that could otherwise be avoided.

    The best way to ensure security in the development process, however, is to start with a strong security foundation. Organizations that understand developers and the development process are savvier when it comes to the vulnerabilities that could be inadvertently introduced and are in a better position to secure them with minimal impact on velocity.

    In such a complex and powerful world of cloud, CI/CD and more, when developers are empowered to let go, organizations can better manage and mitigate risk, and deliver higher quality applications that drive true business impact.

    — Brian Kelly

  • Portable Security Policies: A DevSecOps Primer

    Portable Security Policies: A DevSecOps Primer

    Protecting critical data and applications is a challenge under any circumstances, but it’s especially daunting when resources reside in the cloud. Most organizations today operate a significant portion of their workloads in the cloud, which adds to the complexity of the security problem—a security team can’t fully control cloud environments but is responsible for securing workloads and applications running there.

    Cybercriminals are exploiting the situation. They’re becoming more aggressive and ingenious in their efforts, taking advantage of the fact that there is confusion about who is responsible for which aspects of security under the Shared Responsibility Model. Adding to the chaos is the differentiation between cloud providers’ security offerings and capabilities. Quite simply, in most cases, cloud providers are responsible for the security of the cloud and consumers are responsible for security in the cloud, meaning that security and networking teams still need to ensure their organizations’ workloads and applications are free from malware or other tampering.

    To accomplish this, security and networking teams can’t rely solely on firewalls, threat detection and vulnerability patching to secure vital digital assets. Security tools developed for traditional data centers are not effective at securing workloads in the cloud due to the cloud’s dynamic nature. Security and networking teams must rethink their approach.

    Unfortunately, many organizations are still relying on old and ineffective strategies—further hardening the perimeter, investing in additional threat detection and adding new tools and controls that focus on identification rather than prevention. This security approach has its place, but it does nothing to prevent malicious actors from moving laterally across the network once they achieve a foothold, which leaves cloud-hosted apps and workloads extremely vulnerable.

    Instead, security teams need to enable zero trust in cloud environments, which treats all internal communications as untrusted by default. With zero trust, only authorized applications and services are allowed to send and receive communications, and only in specific ways governed by the principle of least privilege.

    The Second Layer

    Traditional tools aren’t effective in enabling zero trust in the cloud because security and ops teams have a very limited ability to manage all layers of the cloud’s open systems interconnection (OSI) model. Specifically, the lack of Layer 2 controls in infrastructure-as-a-service (IaaS) environments makes tools developed for discrete networks all but useless for locking down ports and controlling or scrutinizing IP addresses.

    Even if an organization manages to implement these tools in the cloud, it cannot provide the level of granularity required to stop malicious lateral movement. For example, when on-premises tools are repurposed for cloud environments, they usually rely on subnets to define the boundaries of communication. Because cloud subnets are designed to handle elastic workloads, they need to be far larger than those in on-premises environments. As a result, cloud workloads are more exposed than is necessary.

    Securely migrating workloads and applications to a cloud environment is a huge and cumbersome job when relying on traditional tooling. The best way to make workloads portable and secure is to decouple workload protection from the underlying infrastructure. In this way, organizations can be certain that any policies applied on-premises can migrate to the untrusted environment of the cloud, without the complexity of mapping changing network addresses, writing policy exceptions or losing fine-grained control during the process.

    Decoupling workload protection from the network requires abandoning a network address-based approach in favor of one based on identity. By using the immutable properties of workloads, security teams can create cryptographic identities for applications and services, which then can be used to determine what is allowed to send and receive communications. Not only does this model provide stronger security, but it also works regardless of where applications are located, because these identities are unaffected when network elements change. What’s more, they can be constructed to tolerate upgrades. By building identity-based policies, security teams can create microperimeters around applications that follow workloads wherever they go, and the policies verify communication across boundaries every time an application attempts to communicate.

    Implementing network-agnostic policies doesn’t just harden security. Software developers benefit as well. Without the roadblock of translating application-speak to network-speak, developers can build software and applications in any environment favorable to their workflow while defining policies to protect their work. Once the software is built, they can securely deploy the finished product to the production environment—even if it is hosted by a third party.

    No organization should have to compromise security to benefit from the efficiencies offered by the cloud and ephemeral auto-scaling containers. Building identity-based policies that enable zero trust and are independent of the underlying network ensures that companies never have to consider making that trade-off.

    — Tom Hickman

  • The DevOps Security Stack

    The DevOps Security Stack

    The whole idea behind DevOps is automation. DevOps automates the development process by eliminating or minimizing human error. If an error occurs, the applications fail quickly so the errors can be resolved promptly on a smaller scale. DevOps and cloud-native applications complement each other perfectly.

    Even though DevOps offers a more efficient and faster way to develop and deploy applications, security remains an issue. On paper, DevOps and cloud-native applications might be more secure than their traditional counterparts, but the reality is not that simple. With the newer, more complex, highly distributed infrastructures common to DevOps come new challenges that need to be identified and addressed.

    This article walks through those challenges to highlight what it takes to secure a DevOps workflow. I won’t focus on specific tools because DevOps is not about specific tools; rather, I’ll focus on the components of DevOps workflows that present special security challenges and explain how to address them.

    The Vulnerabilities You Just Can’t Ignore

    1. Careless use of recycled code

    One way DevOps improves developer productivity is by letting developers recycle code from previous projects or open source repositories such as GitHub. But without proper screening and sanitization, these pieces of code can pose threats to an application.

    1. Multiple platforms make the attack surface larger

    When deploying code in the cloud, you can’t use traditional security services. You need to rethink your security strategy. DevOps teams leverage various platforms, from serverless computing to microservices to multi-cloud in their applications. There’s no single solution to secure cloud-native applications. These applications are highly distributed and have various components, so organizations need a multifaceted approach to better secure these applications.

    1. The dynamic nature of cloud-native applications doesn’t help

    Cloud-native applications are continuously integrated and deployed, which makes it difficult for security teams to identify and mitigate risks. Traditional security tools can’t match the sheer velocity, scale and dynamics of cloud-native applications, leaving them useless.

    1. Secrets need to be secured

    When following the DevOps approach, security professionals need to create privileged accounts and login details and share them over business networks automatically. With serverless applications and the cloud, security teams don’t have a traditional location such as the operating system to execute security policies. A host of useful data, such as keys, storage account credentials, secrets, database passwords and embedded passwords, are stored in repositories. It’s crucial this data is kept extremely secure, as attackers can use this information to cause some serious damage.

    1. Containers can leave your applications more vulnerable

    Since the microservice approach involves a distributed infrastructure, it exposes your system to the network, which makes it easy for attackers to sneak into the system. Containers can be spread across different systems, which makes the threat landscape even larger. Containers are highly replicable, so if there is a vulnerability in one microservice, it can get replicated every time the source code is used.

    Using open source software in containers can make way for an increase in vulnerabilities. DevOps teams should make sure unauthorized containers are not used in production. These containers can be used by attackers to launch an attack on the entire application.

    1. Hosts aren’t automatically safe

    Even if containers are properly secured, the hosts they run on are vulnerable to new threats and day-zero attacks. Container runtime should be up-to-date to avoid risks that can lead to container escape. This can help attackers to take control not only of a container but also the host operating system. So, it is important that hosts are given appropriate protection.

    1. Kubernetes clusters need additional security

    Kubernetes is a widely accepted container orchestration platform. However, it’s difficult for security to be enabled at multiple layers. Kubernetes uses APIs to manage containers, and recently, it was discovered that K8’s API server is quite susceptible to attacks—attackers can make use of the API server to perform malicious activities or install malware in the application.

    Running multiple workloads on one cluster is not a good idea. Sensitive workloads should be run on a dedicated set of machines to avoid attacks through less secure neighboring applications. There’s also a need to secure sensitive metadata, which can be stolen and used to change privileges in a cluster, thereby paving the way for unauthorized changes in an application.

    DevSecOps: The Future of DevOps Security

    In traditional applications, security holds less priority, and security policies are always employed after development is completed. But with DevOps, security can’t be an afterthought. Companies depending on the DevOps approach need to make security their top priority. One of the ways to make sure security is in the foundation of a DevOps implementation is a DevOps security stack. To employ the DevOps security stack, IT teams no longer should be walled off from the DevOps team.

    Security experts’ involvement can help them gain insights into what the application is and how it’s supposed to function so they can identify risks and take steps to mitigate them. This DevSecOps approach has become popular. DevSecOps is a collaboration between the development, security and operations teams who work together to ensure security is at the root of an application, not just on the surface.

    Symantec Cloud Workload Protection: A Modern Solution for Modern Problems

    Most organizations use hybrid cloud storage comprised of workloads distributed among public clouds, private clouds and on-premises, which can lead to an increased attack surface and vulnerabilities.

    Symantec Cloud Workload Protection (CWP) helps organizations monitor and protect their workloads, no matter where they reside. With CWP, organizations don’t have to look for multiple products to meet their many security needs. CWP offers a single console to monitor and manage security across various platforms. It offers automatic discovery of workloads across AWS, Azure and Google Cloud, and visibility into security postures and software, which enables automatic workload monitoring and protection. With continuous delivery workflows and malware prevention, CWP is essential for modern software development.

    Sign up for a free trial of CWP.

    — Twain Taylor

  • Continuous Reliability: How QA and SREs Can Improve Their CI/CD Workflow

    Continuous Reliability: How QA and SREs Can Improve Their CI/CD Workflow

    A key challenge in maintaining and accelerating the speed of software delivery is balancing the rate of change with the reliability of your software. With the move toward an increasingly automated workflow, as well as teams of dozens to hundreds of engineers introducing changes at a high frequency, the ability to identify the issues that will have a severe impact early on becomes critical.

    This challenge poses many questions: With so many errors, will spending my precious time to resolve a particular issue be really worth it? How do I detect severe issues in code or infrastructure that could be impactful ahead of time? Once a release has been moved forward, how can I know how well it’s doing–should it be fully deployed, hotfixed or even rolled back?

    That’s why we need our CI/CD workflow to work both ways, helping us upgrade and improve our application as well as allowing us to learn and adapt according to how it performs with our users. Enter continuous reliability.

    A Feedback Loop Between Everyone

    Code quality gates and contextual feedback loops are the CI/CD building blocks that define the emerging practice of continuous reliability. The current and most common feedback loop is between dev and QA teams, and it’s usually the backbone of every good development cycle. However, feedback loops are relevant to the whole development cycle, and they don’t end with QA/dev deploying and testing elements in staging environments.

    As we all know, production tends to display unexpected and surprise-oriented behavior, some might even say that issues and bugs appear out of thin air. That’s why QA and SRE teams need accurate answers as to the actual quality of releases. They need to identify when critical anomalies move from staging and production, and ideally have the ability to gate them before they harm the application, workflow or customers.

    Defining the Anomalies That Matter

    Anomaly detection is critical to continuous reliability. In most applications, error and performance anomalies can be mapped into three core types:

    1. New defects: the introduction of new errors into a system, usually a result of code changes.
    2. Increasing Errors: an increase in the relative volume (i.e. as compared to throughput) of certain errors, usually as a result of a code or infrastructure change.
    3. Slowdowns: a decrease in the response time of critical parts of the application due to inefficient code or improper provisioning or configuration of infrastructure.

    The introduction of any of these can lead to CPU, GC and IO increases. As such, it is not only imperative that QA and SRE teams gate them from moving into production, but also to prioritize and assign severities that help tackle the most important issues.

    However, detecting anomalies in large-scale systems can be nearly impossible due to a high noise-to-signal ratio, and we’re often left to rely on our users and customers to alert us when something goes wrong. That’s why there’s a need for an objective measure to quantify the quality of a release—one that lies in being able to converge machine learning and critical code-level data to automatically gate bad releases from moving up the chain.

    Continuous Reliability Through Quality Gates

    Once we have an understanding as to what should count as an anomaly within our application, the next step is setting a quality gate to help us identify, understand and hopefully stop bad code from being promoted to production.

    Taking the three core type of anomalies—new issues, regressions and slowdowns—we can evaluate four core quality gates that our code should pass before being promoted:

    1. Error Volume: The normalized error rate of an application, based on calls into the code, should never increase between releases.
    2. Unique Error Count: The number of unique error counts, especially in key applications, should not increase between releases.
    3. New Errors: New errors of a critical type or occurring at a high rate should block a release.
    4. Increasing Errors and Slowdowns: Severe regressions and slowdowns should block a release.

    These four gates can help you define a benchmark that is powerful and broadly applicable to complex environments, but also isn’t complex to the point that it remains an academic exercise. They will help you understand whether your code is ready to be deployed to your pre-production or production environment, and help reduce or even eliminate errors, issues, slowdowns and anomalies within your application.

    — Tal Weiss

  • From ‘Water-Scrum-Fall’ to DevSecOps

    From ‘Water-Scrum-Fall’ to DevSecOps

    As organizations abandon the waterfall method of software development for Agile, many are stuck in what Hasan Yasar terms Water-Scrum-Fall. That is, the organization has not effectively embraced Agile and DevOps principles and remains in silos with no links to business goals. Enter DevOps, an extension of Agile thinking. While Agile embraces constant change and embeds the customer into the process, DevOps embraces constant testing and delivery and embeds operations into the team to internalize expertise on deployment and maintenance.

    This is how Hasan started his talk, “Multi Security Checkpoints on DevOps Platform,” at the All Day DevOps conference.

    Picture5.png

    In his talk, Hasan lays out a plan to get organizations to DevSecOps. Really, DevOps is a risk mitigation strategy, built on situational awareness, automation, and repetition. But, security is where a lot of DevOps implementations fall down. The goals for each organization should be:

    • Protecting private user data
    • Restricting access to data/systems
    • Protecting company data/intellectual property
    • Standards compliance
    • Safeguarding disposition/transition

    But, how do organizations get there?

    First, integration and communication. Every point of the product development life cycle should be integrated and communicating, including among the tools. Once this is achieved, you can automate many, if not most, of the tasks. The automated steps are the ones that require less human actions/input to the software development process. This allows everyone to focus on innovation and better code and less on tasks that can be automated by autonomous systems. Also, tasks that can be automated are less susceptible to errors.

    Picture6.png

    Of course, it is the team that ultimately designs, develops and delivers the software. Your team consists of development, IT operations, quality assurance and security. Each has its own skill set and focus, and the overlap is Secure DevOps.

    Picture7.png

    The team is in place, processes are automated and development has started. Development in this day and age has evolved tremendously from even just a few years ago. Previously, software was limited to size, function and audience, and the supply chain was practically non-existent. Your team built each component. Now, development has grown beyond the ability of an organization to develop outside of its core competencies. The supply chain now involves many sources for the code. It is more like plug and play, and this creates lots of vulnerabilities.

    Hasan notes the software supply chain risk factors:

    • Supplier capability – Does the supplier follows practices that reduce supply chain risks?
    • Product security – Is the delivered or updated product acceptably secure?
    • Product distribution – Does the method of transmitting the product to the purchaser guard against tampering?
    • Operational product control – Is the product used in a secure manner?

    To reduce your supply chain risk, Hasan recommends:

    • Ensure supplier security commitment;
    • Evaluate a product’s threat resistance;
    • Create a centralized private repository of vetted third-party components for all developers;
    • Establish good product distribution practices; and
    • Minimize variation of components to make things easier.

    Finally, as you transition to DevSecOps, remember that security must be addressed without breaking the rapid delivery, continuous feedback model.

    Picture8.png

    You can watch Hasan’s entire talk online here for more details and other tips.

    If you missed any of the other 30-minute long presentations from All Day DevOps, they are easy to find and available free-of-charge here.  Finally, be sure to register you and the rest of your team for the 2017 All Day DevOps conference here.  This year’s event will offer 96 practitioner-led sessions (no vendor pitches allowed).  It’s all free and online Oct. 24.

    — Derek E. Weeks

  • It Is Not All Choice and Speed in DevOps

    It Is Not All Choice and Speed in DevOps

    One of the stumbling blocks starting to show in the agile/DevOps world is that speed of delivery and developer choice are asserting themselves as the primary worthy goals.

    I’m a developer. I have that “look what I did” attitude when I tackle a particularly tough problem and I love it when an environment lets me choose a toolset that helps me achieve my goals faster (or lets me play with tools I have been eyeing for a while). I want to solve problems quickly, and have no issue with stand-ups to show my progress.

    Creative Commons Attribution: winnifredxoxo, flicker
    http://www.flickr.com/photos/61056899@N06/

    But we’ve lost sight of the whole longevity issue, and far too many of us have lost sight of the whole “necessary restrictions” thing, too, which is related. The security environment did not change just because your team went to DevOps with Agile, and what must be supported to keep your cool app up and running didn’t change—at least it didn’t change conceptually. And that’s where we start seeing issues.

    Lori and I were talking this morning, and I came to the conclusion that Ops/DevOps teams would be warranted in saying, “Okay, you want that cool gizmo new thing that is totally outside our architecture, YOU support it.”

    Think about it. Between Agile and “Developers are Kingmakers,” we have set different Dev teams using different environments, from languages to databases to deploy targets to even load-balancers. And while there is a lot of talk about “chuck it over the wall” being gone, the truth is that the responsible Devs will be responsible for code in production, but not the infrastructure that we’re allowing them to inflict upon the Ops/DevOps team. And all of this is done with “timely delivery” as a mantra.

    The problem today is different for security. In security, it is seen by many in the DevOps crowd as inherently slowing down the process. And this, in our current fever dream of rapid delivery, is seen as inherently a problem. Time to step back and see where security can benefit from and add to DevOps. That movement is, thankfully, starting, but needs to be more prevalent. My blog about DB monitoring is an example of DevOps benefitting security, and increasingly the SecureOps movement is showing promise in integrating security with DevOps.

    Do yourself a favor. Look around your IT org. Are there apps running that are 20 years old or older? If yes, speed is still important to business agility, but you have to acknowledge that every unique database/load-balancer/whatever that you introduce is potential technical debt. If you’re working on a core system replacement and have decades-old apps running in your world, chances are pretty good that 20 years from now, someone will be figuring out what you were doing.

    Don’t make it harder than it has to be for future-you. Stick as close to standards as your development effort will allow. It’s been a long time since companies successfully enforced database standards, for example, but having a first choice means that support and training can focus on the first choice. And that 20 years from now, some poor new developer will be able to go “Oh, it’s another MariaDB app.” instead of “What the heck is SuperFastDBForMe, and why are these queries written in pig-latin?”

    And don’t make it easier for hackers by demanding that security not slow down the process. Encourage them to move faster, but it’s not all about speed. In fact, both security and ops were never about speed; they were about thoroughness. The environment and the apps that run in it need to be as secure as is reasonable, and the production environment needs to be as stable as possible. DevOps tends to find itself at odds with both of these facts, sublimating them to the desire to be “agile.” Yes, automation helps with stability, and I’m a huge fan of that. It also helps with the knowledge crunch, but it is more of a shifting of tribal knowledge than an elimination. Someone, in the end, has to be able to modify tools to face the new reality, and that person needs much the same knowledge that they need to do it manually.

    The goals and results of DevOps are great, but if you’re working for an enterprise that will have long-lived apps, just make certain you’re not sacrificing more than you’re gaining. Business agility matters, but so do both security and long-term technical debt.

    Balance, as always, is the way forward. Strive for it early, or struggle for it later.

    — Don Macvittie