devopsy.kinsta.cloud

Tag: security

  • ZeroNorth Extends DevSecOps Orchestration Reach

    ZeroNorth Extends DevSecOps Orchestration Reach

    ZeroNorth has extended its namesake software-as-a-service (SaaS) platform for orchestrating DevSecOps toolchains to include integrations with Scout Suite, Aqua Trivy, Gitlab and BitBucket Server and the configuration management database (CMDB) from ServiceNow.

    The company is also adding application portfolio reports to surface the security policies applied to each application, scan results and progress of remediation work and the ability to customize both alerts and vulnerability data compression parameters, such as rate of compression, name and type of vulnerabilities and libraries.

    Finally, filtering and search tools that can be applied to vulnerability datasets have been added.

    ZeroNorth makes it possible to centrally orchestrate and manage both commercial and open source application security scanning tools via a SaaS application platform.

    Christian J. van den Branden, senior vice president of engineering and product management, said that as DevSecOps processes continue to evolve and mature, most application development teams will employ multiple scanning tools because not every tool discovers every vulnerability. This defense-in-depth approach to vulnerability scanning requires an orchestration tool to integrated multiple scanning tools within a DevOps pipeline, he said.

    That orchestration tool also makes it easier for DevOps teams to prioritize vulnerabilities based on their severity discovered by various static application security testing (SAST) and dynamic application security testing (DAST) tools, noted van den Branden. Tools from vendors such as Qualys, Snyk, Palo Alto Networks, Synopsys and WhiteSource are supported across multiple DevOps platforms.

    In general, van den Branden said a “perfect storm” of security issues is forming in the wake of the COVID-19 pandemic. Organizations are rushing to build and deploy digital business applications that will appeal to end users who increasingly are working from home using largely unsecured networks. Cybercriminals are looking to both compromise applications as they are developed in addition to targeting end users with weak credentials that could be employed to inject malware into applications after they are deployed in a production environment, he said.

    Most IT organizations will clearly need to up their application security game, given the sensitive nature of the digital business processes that need to be protected, he added.

    Ideally, DevOps and cybersecurity teams will meld their workflows to achieve that goal. In many cases, however, DevOps teams will simply extend their existing pipelines to address security issues of their own accord as part of an effort to reduce the number of remediation issues they might need to allocate time to remediate after an application has been deployed in a production environment. That becomes easier to accomplish using a SaaS-based platform to orchestrate DevSecOps processes and pipelines, noted van den Branden.

    Regardless of how IT organizations improve application security time is of the essence. More applications than ever are being deployed across an extended enterprise that now stretches from public clouds to multiple classes of edge computing platforms. Defending that attack surface relying on legacy tools and processes is all but impossible if the code deployed on those platforms is fundamentally insecure.

  • Strengthen API Security With These Tips and Patterns

    Strengthen API Security With These Tips and Patterns

    If you haven’t noticed, digital organizations are building more and more APIs. ProgrammableWeb tracks more than 23,000 public web APIs at the time of writing, and the API market is estimated to be worth $5.1 billion by 2023. Building with APIs increases internal interoperability, reduces development time and can extend product functionality tremendously. In short, the value of APIs is rising. However, opening up with APIs brings security caveats that, if not addressed, could result in serious breaches that negate these benefits.

    I recently spoke with Roey Eliyahu of Salt Security to get his take on the top security concerns for API-enabled companies, and how organizations can safeguard their services. In short, he recommends thoroughly cataloging and understanding your API inventory, designing for legal challenges and mitigating OWASP’s top 10 API security vulnerabilities.

    Challenges for API Security

    APIs have been called “the next frontier in cybercrime.” Rightly so, as API breaches continue to pop up nearly every day. Take the recent API vulnerabilities at Cisco Systems, Shopify, Facebook, U.S. presidential campaign apps, and GCP as evidence. The most infamous was likely the Equifax breach—not enforcing formats on incoming API calls resulted in a massive data breach, which cost the company a $700 million lawsuit.

    So, why have API breaches increased recently? Well, a few years ago, there were simply fewer APIs. And, these older services exposed less sensitive data. Nowadays, companies typically have many more APIs. Banking applications, for example, might expose hundreds of highly valuable endpoints that are very appealing to hackers.

    Companies also build APIs for different audiences: A 2020 study by SmartBear found 72% of companies develop both internal and external-facing APIs. These APIs could easily hold hundreds of parameters, and with every new method added, a company’s potential attack surface grows considerably.

    3 Steps To Secure APIs

    To mitigate the above API security issues, Eliyahu suggested three main steps: Understand your API inventory, audit against privacy policies and data privacy regulations, and track the most pressing API vulnerabilities like a hawk.

    Know Your API Inventory

    “You need a great inventory of APIs to know your attack surface,” said Eliyahu. Many API providers document their APIs with OpenAPI definitions. But, these files don’t always match the production realities—they may be manually generated or leave out certain methods. “In every organization, there is up to a 40% gap between APIs that are actually deployed versus what has been inventoried,” he said. By maintaining a clearer API inventory, organizations can avoid unprotected shadow IT.

    Include Legal Auditing

    A change to an API could result in a change in how it collects user information. Updates involving sensitive data could break privacy policies or regulations such as GDPR. “After you have an inventory, you need to map all parameters manually,” said Eliyahu. He recommended performing a legal audit against your API inventory and establishing a repeatable testing process that plugs into a continuous delivery pipeline.

    As API teams release new updates, they must consider security and legal implications earlier on in the development flow. “Now, with CI/CD, these changes have to happen very frequently,” he noted.

    Watch the OWASP API Security Top 10

    There are many known API security gaps. For example, there may not be proper authorization in place, keys could be exposed, unexpired tokens could be hijacked and so on. Thankfully, OWASP has compiled a resource of top API security vulnerabilities, which Eliyahu and many others in the API economy have rallied behind. “The world should move to adopt the OWASP issues,” he said. These vulnerabilities are as follows:

    1. Broken Object Level Authorization
    2. Broken User Authentication
    3. Excessive Data Exposure
    4. Lack of Resources & Rate Limiting
    5. Broken Function Level Authorization
    6. Mass Assignment
    7. Security Misconfiguration
    8. Injection
    9. Improper Assets Management
    10. Insufficient Logging & Monitoring

    Using AI To Go Beyond ‘Whac-A-Mole’

    Plugging these above holes is a good start. However, these are only defensive measures against known patterns; they aren’t helping you keep guard for nuanced attack types. Ideally, security systems should stop cyberattacks before they even get started.

    Yet, Eliyahu recognizes a big gap in how APIs are monitored. Organizations “don’t have proper tools to know who is looking for vulnerabilities,” he said. “Tools are typically not that advanced. They mainly look for injections and known patterns.”

    Imagine a hacker probing an API. They will likely do so by trial and error, testing undocumented endpoints, sending malformed requests and so on. “They need to probe for hours or days before they find something,” said Eliyahu. If an AI could detect these odd attempts in minutes or seconds, IT could significantly reduce risk.

    Security solutions should thus leverage big data and AI to create baselines of typical behavior, then deter malicious activity the millisecond any nefarious probing begins. Eliyahu said such a security AI must consider dozens of behaviors such as, How is the API being accessed? What parameters are being used? What are the relationships between parameters? What is the flow of API calls? What type of data can be exposed?

    Instead of waiting for a breach to occur, an AI-enabled API security monitoring could instantly pause behavior deemed “out of the norm” by referencing a knowledge base that’s constantly refined using machine learning. Because, if you are only blocking malicious actors without knowing how you need to improve API security posture, “you are just playing Whac-A-Mole,” said Eliyahu.

    DevSecOps Requires API Security Forethought

    Mark O’Neil, analysis at Gartner, predicted that by 2021, 25% of organizations with public APIs will have discontinued or rebooted their public API strategy, citing security concerns as a common breaking point. APIs are now at the core of many application developments. Yet, without the proper DevSec proposition, teams risk wasted efforts and costly breaches.

    To summarize, here are our tips on API security:

    • Ensure everything is well-documented: API inventories cannot be audited if undocumented. Shadow APIs increase the likelihood of an attack.
    • Watch the top 10 OWASP vulnerabilities: These points are foundational to API security. Though not a cure-all, they present a starting point.
    • Build a security and legal review process: Ensure APIs are never deployed without the proper security review. Create validation systems that plug into continuous development processes, so new versions are never breaking privacy policies.
    • Each API is unique: Another thing to keep in mind is each API is unique. Therefore, API security monitoring also requires more context into unique business logic.
    • Continuously monitor your APIs: Continuous search for anyone looking for vulnerabilities.
    • Remove deprecated APIs: Remove old API versions. “You need a mechanism to identify and remove old API versions.” Otherwise, “zombie APIs will bite you!”
    • Learn from the attacks you block: Don’t just play Whac-A-Mole. “You need a mechanism to learn from attacks you block.”
  • Survey Surfaces Lots of DevSecOps Friction

    Survey Surfaces Lots of DevSecOps Friction

    A survey of 560 application security professionals and software developers in North America and Western Europe conducted by WhiteSource, a provider of tools for securing open source software, finds there’s a long way to go before most organizations can claim to have fully implemented best DevSecOps practices.

    Only 20% of respondents said their organization had a mature set of DevSecOps practices in place, while 62% said they were improving. Only 18% described their organization’s approach to DevSecOp as being “immature.”

    There is considerable disagreement concerning how long those efforts have been underway. While 60% of security professionals said they have had an application security program in place for at least a year, just over a third of developers (37%) said they are aware of an application security program running for longer than a year inside their organization.

    Regardless of the length of the program, nearly three-quarters of all respondents (73%) said they feel forced to compromise on security.

    Among application security professionals the top DevSecOps challenge identified was vulnerability prioritization (41%), followed by lack of application security skills (35%), budget (34%), lack of cooperation between developers and security teams (31%) and scanning performance (31%). Less than a third (31%) have a formal process in place to prioritize vulnerabilities.

    There’s also considerable disagreement over whether an application security champion gets designated. Many application security professionals said they have one (60%), while only 40% of developers agreed. The survey also finds well over one-third of developers said their organizations (37%) don’t provide any secure code training. A mere 22% of developers said their organizations provide training regularly with another 20% reporting they have tools that allow for “ongoing independent training.” In contrast, only 27% of application security professionals said their organization does not offer secure code training.

    Lilach Aviad, director of product marketing at WhiteSource, said the survey makes it apparent there are still lots of gaps when it comes to DevSecOps. Most organizations have embraced the concept but are still a long way from unifying workflows to better prioritize which vulnerabilities to address first.

    Priorities are even fundamentally different when it comes to what features are most important in an application security tool. Application security professionals prized integration (48%) most of all, followed by accuracy and ease of use ties at 39%. Developers, in contrast, leaned toward accuracy (25%), followed more closely by integration (22%) and ease of use (21%).

    Overall, the survey found the most widely employed application security tools are penetration testing, web application firewalls and application programming interface (API) gateways. The acquisition of these tools is most often justified to achieve either vertical industry regulations (25%) or industry standards (22%).

    In general, Aviad noted when it comes to security there is still a lot of resentment among developers. Too often security tools have been selected by application security professionals with little regard to how those tools might fit within the context of a larger DevOps workflow, he said.

    Obviously, it’s going to take time and effort for most organizations to merge workflows and culture. The good news is that process has begun in a lot of cases. Less clear is exactly how long it will take to complete.

  • Low-Code, High Risk? Closing the Security Gap of Exposed Source Code

    Low-Code, High Risk? Closing the Security Gap of Exposed Source Code

    There’s no denying that low-code is a rising trend in application development that’s likely to stay for the long run. Its impressive benefits in terms of agility and development time are convincing the enterprise, so it’s no wonder that the industry is on its course to achieve fivefold growth between 2017 and 2022.

    In low-code platforms, building custom cloud applications can be achieved by reusing components through a simple drag-and-drop interface, which means reduced engineering efforts. Then, APIs can be used to hook components together and maximize compatibility.

    Although many steps of the way can be achieved without actively writing a single line of code, many low-code apps include advanced logic written in JavaScript. So, when it comes to understanding the threat model of low-code platforms, we must consider security considerations that arise from using JavaScript code.

    Low-Code and JavaScript

    Because JavaScript needs to be interpreted by a browser to work, it is exposed and anyone can access, read and modify it. This becomes problematic because companies store important business logic on the client-side, which is often unavoidable due to the inexistence of a back end or the need to avoid performance losses. So, companies’ proprietary algorithms and logic end up running on an adversarial environment, which opens the door to a series of attacks—namely, automated abuse, piracy, intellectual property theft and data exfiltration.

    When it comes to protecting code, typically we’re led to the concept of encryption. However, JavaScript encryption is not a feasible strategy; the browser always needs to interpret JavaScript so that it works. If we have a decryption key, we need to supply it to the browser; if that key becomes compromised, all the code will be easily accessed.

    A suitable approach to protect JavaScript is transforming it into a new version that is extremely difficult to understand while also preventing attackers from debugging or tampering with the code.

    When it comes to enterprise or commercial applications, JavaScript must be protected with maximum resilience—that the protected code will prevent attackers from using automated tools against it. On top of this, the code should contain runtime defenses that break the application whenever attackers try to debug or tamper with the app’s source code.

    Conclusion

    Low-code still means a lot of code. Even though most of it will not appear on the front stage, development teams must not forget that it should always be protected. Attackers love low-hanging fruit and unprotected source code of enterprise apps is certainly a low-effort, high-gain venture.

  • Shifting Left With DevSecOps: ESG Report Exposes Difficulties

    Shifting Left With DevSecOps: ESG Report Exposes Difficulties

    A recent report asks the tough questions about DevSecOps adoption, and the results are surprising

    In a world of increasing development velocity, companies are placing more responsibility on developers to enact quick deployments. Naturally, security is “shifting left” as well.

    Theoretically, DevSecOps sounds great, but it opens up many questions. Who exactly is responsible for security knowledge? Are cybersecurity training measures effective? Which tools excel at decreasing risk while maintaining release fluidity? Are AppSec tools aiding or adding unneeded friction?

    A report conducted by Enterprise Strategy Group (ESG) sought to answer these pressing questions and expose trends around application development security. The study surveyed 378 IT, cybersecurity and application development professionals at organizations in North America.

    I recently met with Chris Eng, chief research officer at Veracode, and Dave Gruber, senior cybersecurity analyst at ESG, to dig deeper into the report’s findings.

    Security vs. Development

    There is still friction when attempting DevSecOps in practice. Eng recognizes a disconnect between security and development teams.

    “Most security teams lack an understanding of modern application development practices,” said Eng. Security may not realize how regularly code is pushed or understand the intricacies of tooling within a CI/CD pipeline. On the flip side, developers may not be well-versed in common container exploits and vulnerabilities.

    Organizations are pretty split when it comes to application security testing ownership. Thirty-one percent of organizations dedicate security analysts to manage application security. The development manager and security team jointly own responsibility at 29% of companies. Developer managers follow at 26%, and individual developers at 13%.

    To Eng, these figures reflect an evolution from traditional security testing to the way things are changing with faster development cycles. “Go back 10-plus years, and we had a centralized, dedicated security team responsible for managing AppSec,” described Eng.

    In modern times, security is shared or even furthered where developers themselves run tools by hand or automate security within CI/CD processes. Large companies, Eng noted, now often utilize a mix of those practices.

    Paradox: Secure Yet Vulnerable

    Seemingly, the most eye-opening part of the report was a paradox. The report found that most teams give their application security a high rating (36% gave their application security programs a 9 or 10, with a 7.92 mean). Yet, the majority say they regularly push vulnerable code (48% of respondents knowingly push vulnerable code regularly).

    Though it’s counterintuitive, organizations may knowingly push out vulnerable code for many reasons. “You’ve promised a release, customers are waiting, ” said Eng. “Revenue is waiting. What are the implications of pushing that release?” Teams may not have time to fix vulnerable code, or it may simply not be worth it.

    Publishing vulnerable code may also be a symptom of placing testing too late in the release process. “That’s why there is this trend to shift left,” added Gruber.

    Gauging DevSecOps Success

    The above findings underscore a reality of IT security: To keep pace, software providers must accept a level of risk. In fact, business success may depend on it.

    “The effectiveness of the programs isn’t necessarily measured with how many times you’ve shipped your code with no vulnerabilities,” said Gruber. “Success is that we understand the risk, we have mitigated the risk at the level we believe is right for the organization, and have the right level of control over the process.”

    Companies must weigh the cost of improper DevSecOps and mitigate imminent risk to maintain release agility.

    Application Security Tools: Finding Balance

    At modern companies with quick-release cadences, “CI integrative security tools are way more prevalent and baked into the process,” noted Eng. Yet, 26% of respondents indicate security tooling friction and ineffective tooling usage.

    Whereas InfoSec teams are usually the ones dictating policies, developers have much influence in the tooling selection. Thus, tools must appeal to the developer experience, fitting into their established workflows.

    “We have to build a habit around it,” said Eng. Frictionless tools that continually scan within an IDE, for example, can enable developers to fix an issue on the spot and foster future behaviors.

    At the same time, you must set standards and avoid governance issues. This requires control and observability. “The balance here is that you want developers to be able to integrate something tightly into their toolchain,” said Eng. “But InfoSec needs a bird’s eye view on the organization.”

    Developers Lack Knowledge to Mitigate Issues

    Though security tools may reveal vulnerabilities, they don’t always correlate with remediation. The ESG report found 29% of developers lack the knowledge to mitigate issues identified by security tools.

    There is a clear gap in the market when it comes to developer education around security. This could stem from computer science schooling, in which cybersecurity is rarely taught alongside programming languages.

    On the job, hands-on developer security training is also spotty. Thirty-five percent say that less than half of their development teams are participating in formal training. Only 15% of organizations have developers actively involved in security training.

    Just giving developers a laundry list of vulnerabilities doesn’t help mitigation. For Eng, what organizations require is habitual, recurring training with hands-on tools. “Try to simulate or provide a real-world environment for learning, identifying and patching these issues,” recommended Eng. Integrating tooling within the daily developer workflow can help with knowledge retention, because “if you don’t use it, you lose it.”

    Other best practices will only arise with a security habit. For example, most development environments ship with open defaults. “You need security training and tools to understand to restrict that appropriately,” noted Eng.

    That said, a wide variety of security tooling is already advancing this process. For example, 56% of organizations use API security vulnerability (ASV) scanning to identify and mitigate risk associated with API usage, helping secure applications as developers code dependencies.

    Final DevSecOps Thoughts

    The ESG study found 43% of participants believe DevOps integration is most important to improving AppSec programs. Yet, siloed roles and a lack of security education mean DevSecOps must still mature quite a bit to meet the security-shift-left vision.

    Other eye-opening findings included:

    • More than half of respondents (54%) use automated controls to identify and quarantine vulnerable images in their image repository.
    • The proliferation of AppSec tools on the market is a significant problem for 30% of companies.
    • AppSec spending is increasing, yet only 30% will protect more than three-quarters of their codebase 12 months from now.

    For more findings, check out the ESG Survey Report: Modern Application Development Security.

  • Fastly Sets DevSecOps Strategy After Signal Sciences Buy

    Fastly Sets DevSecOps Strategy After Signal Sciences Buy

    In the wake of acquiring Signal Sciences for $770 million, Fastly is gearing up to expand the range of security services it offers as part of an effort to advance adoption of best DevSecOps practices.

    Artur Bergman, chief architect for Fastly, said a forthcoming wave of edge computing applications will require web applications firewalls (WAF) that can be deployed and managed remotely to protect them. As a provider of a content delivery network (CDN), Fastly will leverage the WAF platform developed by Signal Sciences to secure edge computing platforms within a forthcoming Secure@Edge service that promises to unified web application and application programming interface (API) security.

    Fastly has been gaining ground as a provider of CDN services that are programmatically designed from the ground up to shift control over networking and security services further left toward DevOps teams, said Bergman. In many cases, the only way to secure workloads running on an edge computing platform is for DevOps teams to be able to programmatically deploy a WAF to protect the workloads on that platform, he noted.

    Edge computing platforms are especially vulnerable to distributed denial of service (DDoS) attacks that are increasing in both size and sophistication as cybercriminals become more adept at targeting specific servers and platform, added Bergman. No one can prevent a DDoS attack from being launched, but a CDN can play a critical role in mitigating its impact.

    The acquisition of Signal Sciences comes on the heels of Fastly’s move to expand its the ability to collect metrics from edge computing platforms that will be employed to extend the reach of monitoring tools employed by DevOps teams to edge computing platforms.

    Zane Lackey, chief security officer for Signal Sciences, said the two companies share a similar history and commitment to best DevOps practices. The WAF from Signal Sciences is based on a runtime application self-protection (RASP) architecture that only runs when an application fires up, which Lackey said makes it a natural extension of any DevOps toolchain.

    The Signal Sciences WAF is unique in that it can support multiple classes of monolithic and microservices-based applications and that 95% of organizations that employ it do so in full blocking mode because the number of false positives the WAF generates is limited, added Lackey.

    Naturally, Fastly is not the only provider of a CDN services looking to woo DevOps teams. Organizations have been deploying web-based applications on CDNs for years. However, CDNs that simplify the deployment of applications within the context of a DevOps workflow are gaining traction.

    It’s too early to say how this battle will play out. In addition to providers who have built their own global networks, cloud services providers also now offer CDNs that promise to optimize cloud application performance while enhancing security and simplifying deployment. Regardless of the path forward, it’s clear that as more latency-sensitive applications are deployed across distributed computing environments, the more inclined DevOps teams will be to rely on external network services that can adapt quickly to changing application requirements.

  • Security Assessment

    Security Assessment

  • Security Compass Unveils DevSecOps Platform

    Security Compass Unveils DevSecOps Platform

    Security Compass today launched a DevSecOps platform that guides developers toward building secure applications faster using a set of security analysis tools and processes embedded within it.

    Company CEO Rohit Sethi said SD Elements is the first instance of what the company is positioning as a balanced development automation (BDA) platform. By defining a set of best practices for building secure applications, organizations can strike a better balance between building applications fast and ensuring those applications are secure and compliant with any number of regulatory requirements.

    Too much of the focus on application development is on pure speed, said Sethi. SD Elements is designed to offer a more structured approach that provides developers with access to threat modeling and risk assessment tools to reduce the number of vulnerabilities finding their way into an application.

    SD Elements first gathers details such as the technology stack, deployment environment and compliance requirements. It then classifies risks based on security and compliance policies defined by the organization, which are then employed to surface recommendations to the developer. SD Elements also automatically tracks the status of security activities via integrations with security testing tools such as Veracode, Checkmarx or Fortify to generate reports that identify risks and current mitigation status.

    Finally, SD Elements provides access to a library of thousands of security and compliance recommendations and controls, including code samples and test cases, that are mapped to regulatory and compliance standards from all over the world.

    To some degree DevSecOps will slow down the rate at which applications are developed. Security Compass, via BDA, is making a case for minimizing the impact security gates will have on the rate at which applications are developed. It’s not clear BDA as a market category will catch on, but as providers of DevOps platforms continue to embed security tools in their platforms the entire category is evolving.

    The challenge many organizations face today is they want developers to embrace DevSecOps as part of an effort to shift responsibility for application security to the left. However, organizations are still working to put the tools and processes in place that would enable developers to achieve that goal. Most developers want to build and deploy secure applications; this needs to occur within the context of a structured approach that has a foundation in best DevOps practices.

    Each organization will need to determine to what degree they may need to slow down application development to build more secure applications. In theory, the smaller the workloads the easier it is to secure them while continuing to rapidly iterate. However, that level of DevSecOps maturity takes time and effort to achieve.

    In the meantime, it’s clear DevSecOps has become a requirement as part of an overall effort to better secure the software supply chain on which so many organizations now depend. The challenge is finding a way to adopt DevSecOps in ways that developers will embrace rather than resist.

  • Critical Controls for DevOps: Best Practices for Continuous Security

    Critical Controls for DevOps: Best Practices for Continuous Security

    In relentless pursuit of automation and velocity, DevOps teams can reduce the software development cycle and ensure that their products are responsive to client feedback. However, this quest for perfection may compromise security, leaving room for vulnerabilities or misconfigurations that can create huge problems later on.

    Ensuring security integration throughout the life cycle while retaining agility and speed is necessary to avoid DevOps security risks.

    How can this be achieved? The short answer is understanding the human needs of the security team and realizing the limitations in the workflow.

    DevOps is Trending

    Given the following trends, experts are predicting that DevOps adoption will reach its peak this year.

    • Firms have been showing a rising interest in adopting DevOps-related practices and technologies. Between 2017 to 2018, there has been a 7% spike in DevOps adoption, according to Statista.
    • Notably, the DevOps software market is projected to rise to $6.6 billion in 2022 from $2.9 billion in 2017.

    DevOps Security Challenges

    DevOps teams can be confronted with various unexpected challenges from cybercriminals, including:

    • Unsecured credentials: Intellectual property, such as a company’s source code, can be destroyed if attackers find a way to take advantage of unsecured credentials in a DevOps environment.
    • Overworked team: Since DevOps calls on the software developers to take on multiple roles and discharge a great variety of challenging responsibilities simultaneously, becoming overworked is a strong possibility.
    • Easy-to-access admin credentials: Controlling administrative credentials is difficult in the DevOps model, as everyone can administer systems and debug production issues. Inadequate security may allow hackers to gain complete control over a firm’s IT architecture.
    • Lack of business acumen among security professionals: Owing to the rapid rise in cybersecurity concerns, professionals must be well-versed in business fundamentals to realize how their firm’s threat management strategy is linked to the overall business goals. However, there is a skills gap in the cybersecurity field, which might pose issues for IT companies.

    Key Security Practices to Follow During the DevOps Process

    Having a successful and secure DevOps process requires the company to integrate security practices into each step of the process, from inception to maintenance. A few of these practices are:

    • Providing training to employees from the hackers’ perspective, teaching them how the attacker will take advantage of coding and configuration mistakes or architectural weaknesses, and giving proper DevOps security tools will go a long way in ensuring safety.
    • One of the best DevOps security practices involves regularly updating IT protocols and governance policies. It is worth noting that transparency is a must with DevOps security policy, as it allows employees to feel safe while reporting suspicious internal behavior.
    • Ensure that the engineers behave the way you intend by clearly specifying DevOps security and compliance metrics they must follow.
    • Performing threat modeling in a structured manner is also crucial for a safe development process.
    • Easy to use tools that are integrated into the CI/CD pipeline and intelligent automation solutions can also help achieve security goals without overloading the engineers.
    • Continuously learning and monitoring your applications, infrastructure and network utilizing advanced analytics tools can bolster security measures.

    Adopting a DevSecOps model will enable you to embed code review, identity and access management, configuration and vulnerability management. Although there will be DevSecOps challenges, such as a clash of tools and reluctance to integrate by the employees, these are minor compared to the security benefits.

    Bottom Line

    Implementing security in DevOps is riddled with challenges. Overcoming application vulnerabilities and data breaches during software releases with the above-discussed security practices can help keep DevOps processes, data and teams more secure.

  • Report: As WFH Took Hold, Few Adjusted Their Security Posture

    Report: As WFH Took Hold, Few Adjusted Their Security Posture

    In March of this year, how employees worked (if they were fortunate enough to be able to continue to work), changed dramatically following state-led shelter-in-place orders. At first, it was hoped the shift would be a matter of weeks. But as the pandemic continued and weeks stretched to months—and now with more organizations extending their work-from-home (WFH) policies well into 2021, there’s currently no real end in sight.

    What’s the impact of WFH been on security? Security firm Malwarebytes recently completed a report, “Enduring from Home: COVID-19’s Impact on Business Security,” that looks at precisely this issue. The report examines Malwarebytes’ malware data and a survey of 200 technology and information security decision-makers among large and small organizations.

    The survey found that organizations are confident in their ability to transition to an increasingly remote workforce successfully. Essentially, 73% rated their organization as a high or higher in their WFH preparedness. For those organizations with fewer than 700 staffers, 84% said they moved more than half of their employees to remote work. However, 84% of larger organizations, those with 700 employees or more, said they’d moved almost all their workforce home.

    Disappointingly, despite the profound changes to staff working situations, 45% of those surveyed did not conduct either security or online privacy analyses of their software tools.

    Since the beginning of the pandemic, 20% of respondents said they witnessed security breaches as a result of a remote worker, and 24% said remote worker security breaches created unexpected security expenses. Further, 28% said that they now use personal devices for work more than they did previously, and 61% of those surveyed said that their employers didn’t recommend staff install anti-malware on their personal endpoints.

    Not surprisingly, criminals are adapting to the new worker landscape, adjusting techniques to target poorly configured virtual private networks, cloud services and email. “There has also been a surge in phishing emails that use COVID-19 as a lure to cover up malicious activity. These emails contain commercial malware, such as AveMaria and NetWiredRC, which allow for remote desktop access, webcam control, password theft and more,” Malwarebytes said in a statement.

    The study also found that AveMaria malware increased by more than 1,200% from January to April. This malware targeted primarily large enterprises, the company found. In contrast, Malwarebytes detected a near-doubling in infections from NetWiredRC, which targets small and medium-sized organizations.

    What’s most concerning with these findings isn’t that criminals have shifted tactics due to a change in how staffers work; that’s to be expected and enterprises don’t have control over what attackers will do. But enterprises do have control over how they defend themselves. And as enterprises increasingly turned to cloud and collaboration platforms to make their WFH situations work, they should have updated their threat models to reflect the new reality. As this new reality continues, one can hope organizations better evaluate their current environments and adjust their security posture accordingly.