devopsy.kinsta.cloud

Category: IT as Code

  • This DevSecOps Thing Is Real After All

    This DevSecOps Thing Is Real After All

    Whether you made it to San Francisco, California last month for RSA Conference or not, you don’t want to miss Tuesday’s DevOps Connect: DevSecOps Virtual Summit.

    On Tuesday, July 12, 2022, we are presenting a virtual broadcast of the sessions from our recent DevOps Connect: DevSecOps event at RSA Conference in June 2022. All of the great sessions will be available as well as some bonus sessions that didn’t make it to RSAC.  

    For me, this event was extremely gratifying because it served as validation that I wasn’t crazy all those years ago. When I started devopsy.kinsta.cloud in 2014, I did so because I thought it would be great for security—back then it felt as though I was a lone voice crying out in the wilderness! Now, here we are in 2022 and DevSecOps is real. It is accepted, it is sought-after and it is changing the way software is developed, deployed and managed.

    When I put on the first DevSecOps event at RSA Conference seven years ago, it was a bit controversial. The idea of bringing together the security community with the DevOps tribe was like what I imagine peace treaty negotiations between two warring parties would be. The security folks said no one else cared about security. The DevOps people, like many other IT pros, claimed the security folks were just people who said no to all their initiatives. The lack of trust ran deep. But we kept at it—and while the situation is far from perfect today, so much progress has been made.

    This year’s event featured our best speaker lineup yet. Jim Zemlin, executive director of The Linux Foundation, kicked off the event by talking about open source and security—software supply chain, SBOMs and security, oh my!  Continuing the open source and security trend, CNCF executive director Priyanka Sharma presented a great session discussing cloud-native and DevSecOps.

    And you won’t want to miss two of my favorite sessions. The first involves my friend John Willis asking, “What would Deming do?” in his session at 11:30 a.m. ET. Given the current state of world affairs and the software and security market, what would Edward Deming, the patron saint of DevOps, say and do? John is a bit of a Deming expert himself, so his insights are spot on, I think. And second, Carolyn Wong (who is a superstar) talks at 12:00 p.m. ET in her session about pentesting at scale, pentesting-as-a-service and DevSecOps.

    But wait—there’s more! Chenxi Wang has a powerful session, delivered off the cuff, about the current state of DevSecOps, software supply chain security, investing and more; that’s at 9:55 a.m. ET.

    We’ll also feature two amazing panels: One is made up of the authors of a recent book, Reinventing Cybersecurity. The other features folks from Intel, Mitre, NIST and the U.S. Senate talking about security compliance with an emphasis on software supply chain security and SBOMs (see a pattern here yet?).

    And that’s just the tip of the iceberg—there is even more from this year’s event that you don’t want to miss. So, head on over and register—it’s free. Many of the speakers will be online, live, during their presentations to answer questions, network and offer their guidance. There are also exhibits and sponsor booths and other fun stuff like a yoga class and a DJ spinning great tunes.

    This DevSecOps stuff is real and you will learn a lot from these sessions. We can’t wait to see you there!

    While you’re at it, check out our upcoming CloudNativeDay Virtual Summit August 10, 2022, which is shaping up to be a great event, as well!

  • Dev Job Phisher Steals $540M | Patch OpenSSL NOW | Systemd Dev Joins Microsoft

    Dev Job Phisher Steals $540M | Patch OpenSSL NOW | Systemd Dev Joins Microsoft

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Spear-phishing causes $540 million loss, a high severity bug in OpenSSL might be “worse than Heartbleed,” and Lennart Poettering is now working for Microsoft. (more…)

  • 5 Mean-Time Reliability Metrics To Follow

    5 Mean-Time Reliability Metrics To Follow

    Most folks working in DevOps or SRE roles are familiar with metrics like mean-time-to-recovery (MTTR). Keeping track of the average time a team takes to respond to incidents is crucial to identifying bottlenecks in the support process. It’s also something executives like to show higher-ups when sharing a snapshot of overall platform performance. However, focusing on one single metric might be missing the greater picture.

    For example, how long did it take to discover the incident? How long did it take from discovery until action was taken? What was the timeframe between filing a ticket and updating all clients that had a bug? When can you say you’ve completely resolved an issue? As you can see, there are many potential metrics that could inform software reliability and the platform engineering process. “One number is never going to tell you a complete story,” said Emily Arnott, community relations manager, Blameless.

    I recently met with the Blameless team for a closer look into mean-time reliability metrics. Below, we’ll explore the nuances behind five different types of MTTX metrics and consider the business value of keeping tabs on each type.

    1. Mean-Time-To-Detect

    Mean-time-to-detect is a measurement of how long it takes, on average, to detect that an incident is present. This often happens automatically within a monitoring system. Perhaps a tool sends out an alert when latency meets a certain threshold, for example. But, detection could also come from other sources, such as a customer complaint.

    For example, consider Log4j. Perhaps a runtime vulnerability scanning tool noticed one of your components is impacted by a novel CVE and automatically sent a notification to the appropriate team channel.

    2. Mean-Time-To-Acknowledge

    Now, just because an incident is detected doesn’t mean it’s immediately acknowledged. Mean-time-to-acknowledge, then, is a measurement of how long it takes a human being to realize the incident and begin to act on it.

    In our CVE example, this would be the time between vulnerability detection and initial response. For example, the on-call incident manager received a vulnerability notification, read the exposure details and then filed a JIRA ticket and contacted the relevant team members.

    Many factors might extend mean-time-to-acknowledge. Perhaps someone isn’t logged into Slack, or a hardware issue stalls the notification. Alert fatigue may also get in the way, or there may be a reluctance to file a ticket and introduce more toil. Depending on the severity of the incident, someone simply might not believe the alert is worth responding to.

    3. Mean-Time-To-Recover

    Now, the following metrics are a little more open to interpretation, but we’ll do our best to define each. Mean-time-to-recover is the average time it takes to introduce a temporary fix after discovering an incident.

    For example, if a particular region is experiencing outages, engineers might temporarily divert traffic to a more stable server. This is not a permanent fix, but the system recovers and operations are generally unaffected. This helps maintain the status quo while a more permanent solution is ideated, tested and applied.

    4. Mean-Time-To-Repair

    Mean-time-to-repair (or restore) is the mean time it takes to issue a permanent repair to a system after discovering an incident. In order for a system to be considered fully repaired, it has to not just be working, but working robustly.

    For example, let’s say the incident in question involves performance issues. Perhaps a patch is issued to the core branch to remove bulky code that’s causing slow load times for clients. Mean-time-to-repair introduces a more permanent solution but still might not be the complete resolution to the problem.

    5. Mean-Time-To-Resolve

    Mean-time-to-resolve can be thought of as the average time between when an incident occurs to when the issue is completely resolved. Not only is the core codebase patched, but all clients reliant upon the software have been updated, as well. Lessons are learned and mitigation plans are set to respond to similar incidents or vulnerabilities in the future.

    Mean-time-to-resolve is about resolving the incident entirely, said Jake Englund, senior site reliability engineer, Blameless. This includes addressing the underlying fundamental contributors, completing all logs that remain on the back burner and following up with a retrospective.

    Using Mean-Time Metrics

    Mean-time metrics can provide a quantitative picture of incident response performance, which can be valuable for overall business operations. Mean-time-to-acknowledge, for example, can expose gaps in the remediation process, such as cognitive strife in reporting incidents, said Matt Davis, intuition engineer, Blameless. Understanding these technical and human factors are the first step to making the resolution process swifter.

    Of course, the above metrics rely on incident data, which may not always be a top priority. According to Davis, encouraging a culture that declares incidents—even minor ones such as a configuration change—can improve knowledge sharing within a team. “If you declare an incident, you could enact more systemic change,” added Arnott.

    Limitations of Mean-Time Metrics

    These mean-time metrics do have some limitations. “A number is only one part of the story,” said Davis. As a result, teams might struggle with deciding precisely what to detect. MTTR can be a helpful metric, but it’s the context that matters, he explained. Therefore, tracking multiple metrics can help provide a more sophisticated, nuanced picture. This involves looking beyond averages to consider outlier events, added Englund.

    There are also semantic nuances between the MTTX metrics defined above. “There’s a lot of ambiguity around these words,” said Davis. As a result, organizations might compute each figure differently. Some of these figures use time-markers which may not be technically possible to track consistently, especially since each incident is unique. Demarcating the precise moment an incident began might require guestimation. You might know when a service is fully restored, but the lasting customer perception is harder to gauge.

    Also, another potential downside is that mean-time metrics could easily be manipulated or misinterpreted, whether deliberately or inadvertently. Operations leads might selectively recall specific windows when showing MTTX metrics to higher-ups, leaving out other statistics that paint a different picture.

    Treat MTTX As A Guidepost

    Improving incident response is becoming mission-critical to maintain fully-functional systems as things like outages, downtime, slow speeds and zero-day vulnerabilities can negatively impact user experience. Sometimes, these issues must be addressed immediately to maintain SLAs.

    But tracking reliability averages isn’t all that simple, and they will likely mean something different to each organization. “It’s about embracing complexity and asking the right questions,” said Davis.

    In summary, mean-time reliability metrics provide helpful insight into the ongoing state of incident response. Yet, such metrics shouldn’t be imposed as a strict target — instead, they should be viewed as an informative guidepost. “Metrics can help you find what is discussion-worthy, but it’s not a discussion itself,” said Arnott.

  • Turning Off DevSecOps Noise for Functional Fidelity

    Turning Off DevSecOps Noise for Functional Fidelity

    Analyzing the DevOps and DevSecOps software marketplace demonstrates the high demand for tools and platforms that reduce false positives. As businesses and organizations adopt a rigorous, disciplined software development life cycle and ascribe to strict compliance frameworks, they quickly realize that automated tools can generate a substantial amount of noise, in the form of false positives, that pollute their efforts to maintain a lean and focused operation.

    True Positive Vs. False Positive Vulnerabilities

    Static application security testing (SAST) is fundamentally about using pattern recognition to identify vulnerabilities in code. The more aggressive the scan rules, the more likely a snippet of code will be flagged as a vulnerability; in other words, a “true positive” finding. Automated scanning is fundamental to effective DevSecOps. But if the scanning is too aggressive, it may generate findings that aren’t actual problems; in other words, false positive findings 

    You want your scan to return true positive findings—actual vulnerabilities that can be fixed and remediated. A false positive is a finding that isn’t actually a vulnerability. The ideal tool catches all the true positive vulnerabilities and returns a minimal number of false positives.

    Many platforms give their users granular control over which rules run and are applied to their code. This first layer of control is similar to allowing your team to tune their scans to focus only on certain frequencies while ignoring others. Often, this is used to increase the speed with which a platform might complete a scan. It can also be used to tune out “noisy” rules. It’s perfectly legitimate to use controls like these, but it’s important to recognize that those completed scans aren’t comprehensive.

    Speeding Up Can Slow You Down

    Positive findings, whether they are true or false, take more time and resources to evaluate and remediate. Investing resources to remediate true positives is worthwhile. It would be ideal if they had been caught earlier in the process, but catching a vulnerability before it hits production is the entire reason you are doing DevSecOps in the first place! False positives may not require actual remediation, but reviewing them and then manually confirming their false nature is directly counterproductive to the reasons an organization adopted automated SAST in the first place.

    SAST Plus DAST Keeps You Ahead

    The gold standard for effective security testing is to pair SAST with dynamic application security testing (DAST), sometimes also called interactive application security testing (IAST). This process will correlate the positive findings from the SAST scans and test them using simulated data in an emulated runtime environment. 

    DAST/IAST actually tests each bit of code that looks problematic because of a particular pattern and then tests whether the code is actually vulnerable. DAST provides an automated, testable, repeatable and provable method to test those positive findings for trueness and falseness. If you are only doing SAST scanning, then the noise-to-signal ratio from your platform is governed strictly by the intelligence embedded into their pattern-matching code. Depending on the quality of the tool being used, your actual mileage may vary.

    DevSecOps Is the Right Path

    Businesses and organizations clearly understand the problem of potential vulnerabilities. Guarding against a security breach is critically important to protecting proprietary information and the privacy of their customers. DevSecOps is clearly the right path to take to reach that goal. However, it is critically important that the vehicle(s) these teams use to get there (in this case, SAST and DAST/IAST) have built-in functionality to focus their efforts on real problems and not waste it on phantom issues.

  • More Than Half of DevOps Pros Have Backdoor Access to IT Infrastructure

    More Than Half of DevOps Pros Have Backdoor Access to IT Infrastructure

    A survey of 600 DevOps professionals conducted by strongDM, a platform for managing access to IT infrastructure, found nearly two-thirds (64%) had productivity impacted on a daily or weekly basis because of access issues.

    It’s not surprising that, as a result, DevOps teams created a number of workarounds to gain access, even though those methods don’t comply with cybersecurity best practices, according to the survey. More than half of respondents (55%) maintained backdoor access to systems, and 42% have embraced shadow IT to get access to tools and systems they needed for their roles, the survey found.

    Worse yet, the survey found that 53% of respondents admitted they are sharing credentials across teams.

    Well over half (57%) of respondents said it could take days or weeks for access requests to be approved, with 40% reporting it takes days to add tools to existing access solutions. Nearly three-quarters (73%) of respondents also noted it requires 15 minutes or more to gain access to infrastructure.

    More than half of respondents (52%) said they have missed deadlines due to issues with accessing infrastructure, with 53% of those respondents being held accountable for the missed deadline even if it was caused by their lack of access to infrastructure.

    Justin McCarthy, CTO for strongDM, said despite all the hype surrounding identity management and zero-trust IT, it’s clear many organizations are still struggling with the basics of access control. That issue has been further exacerbated by the need to enable more DevOps professionals to work from home since the start of the COVID-19 pandemic more than two years ago, he added.

    Many of those organizations are still relying on virtual private networks (VPNs) even though it’s been shown that stealing the credentials to access those VPNs is relatively trivial, McCarthy added.

    In place of those approaches to access IT infrastructure, strongDM is making a case for a dedicated infrastructure access platform that manages and audits access to databases, servers, clusters and web apps. It is based on local client software, a gateway intermediary and configuration tools that track roles and permissions.

    The benefits of that approach span everything from lower IT support costs to faster onboarding of new IT staff, noted McCarthy.

    Managing infrastructure access for DevOps teams is, of course, always going to be a challenge. DevOps teams are made up of engineers—among the most challenging types of end users to support. Many of them will use their own expertise to circumvent any process they deem to be inefficient. The trouble is, many of those end-runs would not pass muster with cybersecurity teams responsible for access management. The challenge each of those cybersecurity teams needs to come to terms with is the amount of time they want to spend time looking for these cybersecurity policy workarounds versus making it easier to securely access IT infrastructure.

    The sad truth is both DevOps and cybersecurity professionals are wasting a lot of time and effort trying to outwit each other when that time could be put to better use.

  • Survey Reveals High Cost of Application Modernization

    Survey Reveals High Cost of Application Modernization

    A survey of 250 software developers and architects in the U.S. found nearly three-quarters of respondents (74%) reported that the average cost of an application modernization project is nearly $1.5 million, with 79% noting that at least one of these projects has failed.

    Conducted by Wakefield Research on behalf of vFunction, a provider of a platform that automatically converts monolithic applications into microservices, the survey polled developers and architects at organizations with 5,000 or more employees that have been in business for at least 15 years and are maintaining Java applications. The survey found that the primary reasons application modernization projects failed were expectations not being set correctly (43%) and the need for organizational structural changes (37%).

    Despite the cost and inherent risks, however, the survey also found a full 92% of respondents planned to or are currently modernizing applications. Nearly two-thirds (62%) said having the right resources and tools is the key to application modernization success.

    Well over half of the respondents (58%) also noted that, on average, it takes 16 months to complete these projects, with more than a quarter (27%) noting it takes two years or more. Not surprisingly, a full 97% said they expected someone in their organization would push back on a proposed project.

    Application modernization, of course, is something of a catch-all phrase that can involve everything from providing applications with a web frontend to lifting-and-shifting them into the cloud or completely refactoring them to run natively on a cloud platform.

    vFunction CEO Moti Rafalin said that regardless of the scope of the initiative, most organizations should first pick these projects based on what makes the most sense for the business. Once identified, it then becomes critical for IT teams to have a deliberate strategy in place to achieve that goal given the high cost of failure, he added.

    Organizations would also be well-advised to determine how job roles will evolve, because one of the biggest inhibitors to application modernization is concern over how any job might be impacted, noted Rafalin.

    It’s not clear how quickly organizations are opting to modernize existing applications versus replacing them outright. However, as more organizations opt to run applications in the cloud, the level of interest in using microservices to build applications has risen sharply. The goal is to employ microservices to make applications both more resilient and secure. The tradeoff is that microservices-based applications tend to have lots of dependencies that make them more challenging to manage and secure.

    Regardless of approach, it’s more a question of when an application will be modernized or retired versus if. The level of technical debt that accrues over time for each application eventually becomes unsustainable. The issue, of course, is that most organizations don’t have the resources required to modernize every application at once, so it may take a decade or more to work through an entire application portfolio—even as that portfolio continues to grow. In fact, as technologies continue to evolve, it may turn out that application modernization is not a task to be completed as much as it is a permanent state of IT affairs.

  • TechStrong Con: Open Source Software Community Needs Security Help

    TechStrong Con: Open Source Software Community Needs Security Help

    The only way to make significant improvements in the state of open source security is if more organizations that benefit from open source projects commit to making more resources available to achieve that goal.

    At the virtual TechStong Con event, executives on an Open Source and DevOps panel called for more contributions from enterprise IT organizations to ensure the integrity of open source software.

    Organizations of all sizes now benefit from open source software whether directly or indirectly. Those organizations have a responsibility to participate in the development of that software in any way they can, said Jeffrey Barnes, senior software engineer for Remote Operations, a provider of medical transcription services. “We need to give back to the community,” he said.

    Those efforts don’t necessarily have to involve contributing actual code, added Barnes. Many open source projects are in need of documentation and testing help because the number of actual maintainers of the project is relatively small, he noted.

    The challenge is that many enterprise IT organizations don’t understand how to participate in open source software development processes, noted Tom Sweet, CIO for Industrial Refrigeration Pros. An organization might download a piece of open source software and then extend it. Rather than continuing to maintain that branch on their own, organizations should contribute that code back to the project to reduce maintainers’ overall IT burden, Sweet said.

    “Many organizations are struggling to contribute back,” said Sweet. “It’s an evolution.”

    Organizations clearly need to make contributing code back to open source software projects a natural extension of their DevOps workflows. In the meantime, the Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, is focusing on 10 streams of investment that, in total, would require more than $150 million in funding to drive greater adoption of DevSecOps best practices among maintainers of open source software projects.

    The core issue is that many of those projects are maintained by a small number of programmers that voluntarily contribute their time and effort to build components that others are free to use. Like any other developer, the amount of security expertise those individuals have is limited. The onus for making sure the projects and software are secure is on the organizations that decide to deploy that software.

    Unfortunately, many IT vendors and large enterprise IT organizations reuse that code without contributing anything meaningful back to the project—whether that be in terms of financing or helping open source maintainers find and remediate vulnerabilities.

    It’s not clear to what degree business and IT leaders realize how dependent their organizations actually are on open source software. Many of them assume that open source projects are supported by IT vendors when, in reality, there are many projects that are dependent on the efforts of a small handful of developers volunteering their time and skills.

    Many organizations, of course, may soon decide not to employ open source software if it doesn’t have a critical mass of developers working on it. However, in an era where DevOps teams and developers routinely download software, enforcing those policies is going to be problematic. The best thing enterprise IT organizations can do is engage with the open source software community more rather than less.

  • Developer’s Guide to Web Application Security

    Developer’s Guide to Web Application Security

    When it comes to security, there are many vulnerabilities that can leave your website or web app open to attack. In this article, we’ll go over 15 common web application security vulnerabilities and how you can prevent them.

    1. Insufficient Cryptography

    Cryptography is a critical security measure that is used to protect data in transit and at rest. Yet, many web applications do not use cryptography properly, leading to a number of serious vulnerabilities including potentially devastating code theft. For example, data can be easily intercepted and read if it is not properly encrypted or encryption keys can be easily guessed or stolen if they are not properly protected.

    To properly protect data, it is important to use strong cryptography. This includes using proper encryption algorithms, encrypting data in transit and at rest, properly protecting encryption keys and more. It is also important to keep all software up-to-date, as new cryptography vulnerabilities are constantly being discovered.

    2. Broken Access Control

    Access control is a security measure that controls who has access to what data and functionality in a system. It is an important part of any web application but often is not implemented correctly. This can lead to serious vulnerabilities such as sensitive data being leaked or attackers gaining access to administrative features.

    There are a number of common mistakes that can lead to broken access control, such as failing to properly restrict access to data and functionality, using insecure methods for storing and transmitting user credentials and not properly protecting session tokens. In order to prevent these kinds of vulnerabilities, it is important to implement proper access control measures in your web application.

    3. Broken Authentication and Session Management

    Authentication and session management are two of the most important security measures in any web application. Yet, they are very often not implemented correctly, leading to a number of serious vulnerabilities. For example, session ID’s can be easily guessed or stolen, cookies can be tampered with and passwords can be brute-forced.

    In order to properly protect user data and prevent these kinds of vulnerabilities, it is important to implement strong authentication and session management mechanisms. This includes using strong passwords, two-factor authentication, proper session expiration and invalidation, and more. It also means properly protecting any session IDs and cookies that are used by the application.

    4. Cross-Site Scripting

    Cross-site scripting (XSS) is a type of vulnerability that allows an attacker to inject malicious code into a web page. This can be used to steal data, hijack sessions, redirect users to malicious sites and more. XSS is one of the most common web application vulnerabilities, especially in our era of remote work. Despite security awareness training, many employees remain vulnerable to social engineering and phishing tactics when these risks are not properly addressed.

    To protect against XSS attacks, it is important to sanitize all user input and output. This includes properly escaping special characters, using a whitelist of allowed characters and more. It is also important to keep all software up-to-date as new XSS vulnerabilities are constantly being discovered.

    5. Insecure Direct Object References

    Insecure direct object references (IDOR) are a type of vulnerability that allows an attacker to directly access data that they should not have access to. For instance, an attacker could guess or brute-force the URL of a sensitive file, such as a customer’s credit card information, and then download it. IDORs can also be used to bypass security measures such as access control checks.

    In order to prevent IDOR vulnerabilities, it is important to properly validate all user input and restrict access to data and functionality to only those who are supposed to have access to it. It is also important to keep all software up-to-date as new IDOR vulnerabilities are constantly being discovered.

    6. Insufficient Authorization and Authentication

    Insufficient authorization and authentication is a type of vulnerability that allows an attacker to gain access to data or functionality that they should not have access to. This can be due to a number of factors, such as weak passwords, improperly implemented role-based access control, deliberate over-permissioning and more.

    To properly protect data and prevent these kinds of vulnerabilities, it is important to implement strong authentication and authorization mechanisms. This includes using strong passwords, two-factor authentication (2FA), proper role-based access control and more. It is also important to keep all software up-to-date as new vulnerabilities are constantly being discovered.

    7. Failure to Restrict URL Access

    Another common web application security vulnerability is the failure to restrict URL access. This can allow attackers to gain access to sensitive data or functionality that they should not have.

    One of the most common problems developers face is forgetting to properly restrict access to directories and files. For example, they may forget to add an index.html file to a directory. This oversight would give anyone who accesses that full directory read and write access to all the files in it.

    Another common issue is that developers do not properly restrict access to certain URL parameters. For example, they may allow anyone to access the “id” parameter, which could be used to view or modify data that they should not have access to.

    To prevent these kinds of vulnerabilities, it is important to make sure that all directories and files are properly restricted and that all URL parameters are properly sanitized before being used.

    8. Remote File Inclusion

    Remote file inclusion (RFI) is a type of vulnerability that allows an attacker to include a remote file, usually through a script or other type of application, on a vulnerable web page. This can be used to inject malicious code into the page which can then be executed by anyone who views it.

    One of the most common problems with RFI is that developers do not properly sanitize user input, which allows attackers to inject their own files into the page. Another issue is that developers often use static include paths which makes it easy for attackers to guess the path and inject their own files.

    To limit these kinds of vulnerabilities, it is important to make sure that all user input is properly sanitized and that dynamic include paths are used.

    9. Insufficient Logging and Monitoring

    Logging and monitoring are critical security measures that are used to detect and respond to security incidents. Despite these critically important functions, many web applications do not properly log and monitor activity, leading to a number of serious vulnerabilities. For example, an attacker could easily cover their tracks or an incident could go undetected if there is not proper monitoring in place.

    In order to properly detect and respond to security incidents, it is important to properly log and monitor activity. This includes logging all activity, monitoring for suspicious activity and more. It is also important to keep all software up-to-date, as new logging and monitoring vulnerabilities are constantly being discovered.

    10. Security Misconfiguration

    Security misconfiguration is a type of vulnerability that arises when a web application is not properly configured. This can lead to a number of serious security issues such as exposing sensitive data, making it easier for attackers to gain access to systems, and more.

    To mitigate risk when it comes to these kinds of vulnerabilities, it is important to properly configure all software and systems. This includes setting strong passwords, disabling unnecessary accounts and services, properly configuring firewalls and more. It is also important to keep all software up-to-date as new security misconfiguration vulnerabilities are constantly being discovered.

    11. Tampering with Data

    Data tampering occurs when an attacker tries to modify data without permission. This can end up having a number of serious consequences, such as corruption of data, loss of data integrity and more.

    To prevent data tampering, it is important to properly protect data through data handling and storage best practices. This includes using proper authentication and authorization mechanisms, encrypting data in transit and at rest, properly protecting encryption keys and more. It is also important to keep all software up-to-date as new data tampering vulnerabilities are constantly being discovered.

    12. Cross-Site Request Forgery (CSRF)

    Cross-site request forgery (CSRF) is a type of vulnerability that allows an attacker to trick a user into submitting a malicious request. The goal is to be granted requests to do things without the user’s knowledge or consent, such as changing their password, transferring funds and more.

    To prevent CSRF attacks, it is important to properly validate all requests. This includes using proper request validation mechanisms, such as checking for a valid CSRF token, 2FA and more.

    Be Aware of Vulnerabilities

    We use and rely on a large number of web apps in our daily and commercial lives. While most of these apps are relatively safe and secure, there are still a number of common security vulnerabilities that can leave them open to attack.

    To keep your web apps safe and secure, it is important to be aware of these vulnerabilities and know how to prevent them. This includes keeping all software up-to-date, using proper authentication and authorization mechanisms, encrypting data in transit and at rest and training users to identify social engineering and phishing attempts, among others. By following these best practices, you can help to ensure that your web apps are as safe and secure as possible.

  • Survey Sees Alternative Cloud Service Providers Gaining Ground

    Survey Sees Alternative Cloud Service Providers Gaining Ground

    A survey of 458 development professionals, managers and senior leaders conducted by Techstrong Research, a sister entity of devopsy.kinsta.cloud, found 43% are considering adding additional cloud service providers in the next 12 months. In total, nearly two-thirds said they are at least considering, evaluating or are ready to buy from a trusted alternative cloud vendor, with 20% reporting they have already contracted one.

    The survey, conducted on behalf of Linode, an arm of Akamai Technologies that provides cloud services, found a full 93% of survey respondents are already using either Amazon Web Services (AWS), Microsoft Azure or Google Cloud Compute Platform (GCP). Nearly two-thirds (65%) reported they already used more than one cloud service provider. More than a quarter (28%) said they are using alternative providers to augment services they consume from either AWS, Microsoft, Google, Oracle, IBM Rackspace or Alibaba. And 19% said they are using a hyperscaler and an alternative cloud service provider.

    The biggest drivers respondents cited for using alternative providers are reducing reliance on a single provider (55%), improved price/performance (38%) and recent cloud outages (31%).

    Respondents also said they are concerned that large providers might one day compete with them as they expand their reach into other industry segments (24%) or may engage in business practices that would create a moral conflict (19%). A quarter (25%) said they already viewed their cloud service provider as a competitor.

    Dan Kirsch, principal analyst for Techstrong Research, said as cloud computing continues to mature, it is becoming apparent that more organizations are considering their options when it comes to consuming commodity compute, storage and networking services. Many organizations simply don’t need to access complex cloud services, he noted. A total of 42% of respondents said a cloud service provider offering core infrastructure primatives could handle 90% of their typical workloads. In many cases, alternative cloud service providers are being used to augment rather than replace a hyperscale cloud service provider, noted Kirsch.

    Overall, nearly three-quarters of respondents (74%) said they expect their infrastructure will be cloud-based by the end of this year. Nearly three-quarters of respondents buy cloud services directly from an infrastructure provider, with the rest employing a managed services provider or some other type of third-party cloud services reseller.

    More than one-third of respondents also reported using a payment mechanism other than a contract or request for proposal (RFP), according to the study. Among customers of alternative cloud providers, more than two-thirds (67%) are using some other payment mechanism, with one-quarter using cryptocurrencies to pay. That option is becoming increasingly important because more organizations are looking for ways to reduce costs by employing alternative payments, said Kirsch.

    In other cases, IT professionals are looking for an end-run around cumbersome purchasing processes or simply opt to use alternative payment methods as a matter of personal preference, he added. Alternative providers, as a general rule, are more open to processing these types of payments, noted Kirsch.

    The shift to the cloud has clearly been accelerating since the start of the COVID-19 pandemic. But as the landscape continues to evolve, there are now more options than ever for IT organizations to consider as the cloud becomes the preferred platform on which to deploy applications.

  • Four Steps to Avoiding a Cloud Cost Incident

    Four Steps to Avoiding a Cloud Cost Incident

    The recent Flexera 2022 State of the Cloud Report found that organizations waste 32% of their cloud spend, up from 3o% last year. This can be due to cloud cost incidents triggered by unused resources, malicious activity or overambitious projects and which have a massive financial impact if not found and corrected promptly.

    As an organization’s cloud infrastructure footprint matures, mapping cloud resource use and costs accurately to product lines, teams and business units becomes progressively more complicated and problematic. However, accurate cloud cost attribution is vital to understanding team resource use and determining accurate cost of goods sold (COGS) margins and is imperative to budgeting and forecasting. Organizations need reliable, granular views of the cloud environment to attribute costs back to departments and optimize a meaningful budget.

    Cloud cost spikes can blow up an organization’s budget fast and can be hard to track down, but enterprises can help protect themselves from a cloud cost incident with just a few simple steps.

    Have a Strong Tagging Strategy That Attributes Cost Granularly

    The cloud operations team needs to identify what is important to business reporting, which will help define and create a strategy for tagging. For instance, when an organization has two teams managing a particular service, the teams should safeguard the services tagged with a team identifier. Also, the teams should add another tag for the environment in which they’re running so they can allocate cloud costs across teams and environments.

    When an application uses numerous resources, like a database and storage, teams should consider adding a specific application tag and break down costs by each application. It should be noted that there is no one-size-fits-all tagging solution, so enterprises will need to determine what works and try out different strategies by adding and removing tags later.

    Understand Cloud Cost Ownership to Avoid Chaos

    Ask yourself how well your organization has attributed cloud costs to teams, applications or COGS. If the answer is “Not well,” then you are missing vital information about how your cloud costs relate to your business.

    The lack of this context or visibility into resource allocation makes it unmanageable and impossible for cloud operations owners and senior leaders to agree on who is responsible for varied expenses and resources. Manual cost attribution doesn’t scale accurately or account for shared cluster resource use across teams and applications. This creates confusion that can escalate when users arbitrarily slice data and claim ownership without accountability or clear visibility.

    What happens is that costs can sometimes be double-counted with two owners—or even missed completely with no owner whatsoever. The resulting data emerges as an inferior quality that is untrustworthy and not actionable. The inability to visualize resource use in context can dilute, hinder and even defeat cost improvement initiatives and optimization.

    Cloud costs should have an owner who can ensure that cloud spending is tied to business value. Understanding who owns which pieces will help pinpoint the cause.

    Establish and Monitor Cloud Budgets

    Historical data on cloud spending is gold—it can help forecast and budget for what should be happening with the cloud’s cost footprint. If that’s not happening, then it should be flagged and investigated.

    Once you get cost data under control, organizations can get an accurate picture of where cloud spending is taking place. However, does this match the expectations of spending? By establishing and monitoring budgets at every stage of a project, organizations can have guardrails to cloud spending and prevent costs from soaring out of control when engineers overallocate on performance “just in case.” Once budgets are in place, organizations can monitor spending and right-size resources to balance actual usage, rather than estimated usage at the start of execution.

    Over time, right-sizing resources will allow for optimal spend, as well as identify unused resources that can be shut down. Organizations should identify development and test instances left running when no longer needed and shut them off.

    Implement Cost Anomaly Detection

    Organizations can shield themselves from cost anomalies by continually monitoring and optimizing cloud costs. Cost anomaly detection can help act as a barrier to early recognition before they become problematic. This is especially effective when prompt, actionable alerts can be delivered directly to resource owners via Slack or email when their forecast exceeds the set budget. The best option would be adopting a cloud cost monitoring and optimization (CCMO) tool that gives alerts in real-time when a cost anomaly occurs. These tools must be able to detect anomalies and analyze their root cause, while also allowing visibility into what went wrong to avert similar future errors.

    Executing continuous cost monitoring and anomaly detection tools for dynamic cloud environments is essential in identifying any activity that doesn’t align with expected expenditure or diverges from an established pattern. With proper monitoring, organizations can take corrective measures before the fact.

    Unwanted and unexpected cost incidents can clean out an enterprise’s budget quickly, especially as its cloud infrastructure grows. Organizations need to practice these steps to gain a full picture view of their cloud environment.