devopsy.kinsta.cloud

Tag: security

  • GitLab Presses Case for DevSecOps Collaboration

    GitLab Presses Case for DevSecOps Collaboration

    GitLab today at its GitLab Commit Virtual event pledged to make securing its open source continuous integration/continuous delivery (CI/CD) platform a more collaborative effort.

    Cindy Blake, senior security evangelist for GitLab, said the company is committed to sharing a road map developed in collaboration with DevOps teams that lets organizations see what cybersecurity issues will be addressed when.

    Rather than merely sharing DevSecOps marketing collateral, Blake said the goal is to encourage engineers to participate in a feedback loop that will help prioritize what issues need to be addressed across a shared DevSecOps agenda.

    Most of that effort thus far has focused on making tools for scanning for vulnerabilities a natural extension of a DevOps workflow by embedding them into GitLab Core. Most recently, GitLab acquired Peach Tech, a provider of protocol fuzz testing and dynamic application security testing (DAST) API testing tools, and Fuzzit, a continuous fuzz testing tool. The company also moved to make its CI/CD platform available as a set of hardened Docker container images.

    The next priority is to enable organizations to construct DevSecOps workflows spanning DevOps and cybersecurity teams, said Blake, noting it will be easier to construct workflows at scale using a CI/CD platform that tightly integrates all the tools required.

    In time, GitLab plans to extend those efforts to include machine learning algorithms that will be trained to identify and remediate cybersecurity issues, she added.

    As a founding member of the Open Source Security Foundation, GitLab is also committed to working with the rest of the open source community to better secure software, Blake said.

    There’s naturally a lot more focus these days on application security. A recent Global DevSecOps Survey conducted by GitLab finds developers are exercising more control over security—more than 25% of developers reported feeling solely responsible for security, compared to 33% of security team members who say they own security. A total of 29% of respondents said they believe everyone should be responsible for security.

    However, cybercriminals are also making a concerted effort to compromise software supply chains by inserting malware into DevOps workflows constructed on CI/CD platforms. The challenge with securing open source platforms, of course, is the code employed to build these platforms is accessible to anyone including, of course, cybercriminals.

    It’s too early to say to what degree cybersecurity concerns are influencing the selection of CI/CD platforms. However, as cybersecurity professionals become more involved in application development, it’s only a matter of time before issues involving the security of the platforms used to build applications become a higher concern.

    In the meantime, the line is blurring between application development and cybersecurity. The challenge for each organization will be determining just how far left they want to shift responsibility for cybersecurity to the individuals who build their applications versus a cybersecurity team that has a less vested interest in accelerating the rate at which code is promoted into a production environment.

  • DevOps and Compliance: A Recipe for Success

    DevOps and Compliance: A Recipe for Success

    In today’s world, DevOps and compliance teams need to work together, not separately

    Imagine this: You organized a dinner party weeks ago, promptly forgot about it and just realized tonight’s the night! You have two hours to whip up a gourmet meal for 10 friends. Instead of panicking, you get smart and enlist your kids to form an assembly line. One starts on sides, the other maps out dessert and you begin marinating steaks. All goes well—until the Brussel sprouts burn. Glancing at your watch, you sigh in relief—there’s just enough time to make another batch.

    At that moment, your spouse walks in and assesses the situation. The meat is a tad underdone, the veggies could be crispier and the cake is lopsided. You can’t serve this meal! But now your guests are knocking. What do you do?

    And more importantly, how does this scenario translate into a genuine business imperative?

    The DevOps and Compliance Divide

    In many ways, this dinner party dilemma exemplifies the clash between DevOps and compliance teams when it comes to priorities and perspectives.

    • The DevOps PoV: Sure, we had a few hiccups along the way, but the end result smells and tastes amazing. Best of all, it’s hot, plated and ready on time for everyone to eat.
    • The Compliance PoV: Yes, but the steak is 144°F. It needs to be 145°F to be considered safe. Boiling the veggies instead of steaming them depletes important vitamins from the meal. And both layers of the cake need to be exactly 2 inches tall.

    Why the great divide? For starters, their reasons for being are at odds. The DevOps philosophy combines people, processes and tools to empower software developers and speed the delivery of high-quality applications, all while cutting costs. It’s also flexible, iterative and imperfect—experimentation is embraced. Imagine someone saying, “We’ll improve it in the next sprint.”

    In contrast, compliance is all about order and uniformity; there aren’t any gray areas. Compliance teams are in place to make sure an organization’s security controls are implemented and monitored consistently. They adhere to a set of rules, mandated by a security framework, government body or customer contractual terms.

    Yet in today’s world, these teams need to “cook” together—not separately. And that’s not easy.

    Can’t Have One Without the Other

    Compliance is a business imperative. Adhering to external regulations and the demands of your customers is of the utmost importance. If you think compliance is extraneous or expensive, try non-compliance. And it’s not just about avoiding millions (or even billions) of dollars in fines. It’s about maintaining trust. According to an IBM study, 53% of consumers say how well businesses protect their data from a cyberattack is “extremely important,” while 64% have opted not to work with a business due to concerns about whether they could keep their data secure. A company’s internal rules and controls are also implemented for good reasons, from instilling accountability to meeting customer requirements. They are not optional.

    But neither is DevOps. It’s proven to boost competitive advantage by speeding up software delivery. In fact, high-performing IT teams that implement DevOps practices are more agile, deploying software and changes 46x more frequently with 440x faster lead times than their lower-performing peers. DevOps is also driving digital transformation by streamlining operations, cutting costs, accelerating agility and response, breaking down silos, challenging long-held mindsets, encouraging experimentation and cultivating collaboration, productivity and overall job satisfaction.

    2 Cooks in the Kitchen: 5 Steps for Making it Work

    So, how can two diametrically opposed “chefs” work in concert to create masterpieces? It’s a question that many CISOs and compliance officers are grappling with …

    How do I do my job without standing in the way of DevOps?

    To find the answer, they must ask another, broader question …

    How do I get complete and continuous visibility of the risks impacting my business?

    The only way to do this is to embed automated, transparent risk management into the entire DevOps process. Here’s how to get started:

    • Open Up. Compliance and security teams need to be clear about what’s required of DevOps teams. Effective, ongoing communication and granular details will ensure DevOps teams understand their responsibilities and are empowered to do their part. This open line should flow both ways. DevOps teams should be transparent with compliance about their processes, ask lots of questions and understand how their actions will impact the business.
    • Get Leadership On Board. Widespread change across people, processes and tools requires support from the top. Executive teams have to believe in it and back it. This will help your organization push through the tough times, convince the cynics and ensure sustained success.
    • Make Training a Two-Way Street. Train security teams in DevOps processes—it’s easier to protect what you can understand. And involve security in developer training, from attack “post-mortems” to sharing source code repositories.
    • Embed Security from the Start. Most organizations have multiple security scanning tools in place to identify vulnerabilities at different points in the DevOps process. But this often leads to alert overload, security gaps and more questions than answers. Consistent security scanning should be integrated across the software development life cycle and issues should be monitored in a consistent, centralized manner.
    • Embrace Automation. This helps organizations understand where vulnerabilities repeat themselves and which ones present the most risk, empowering developers to address real issues quickly so they can get back to business.

    Just like perfecting a signature dish, bringing DevOps, security and compliance into alignment takes time. It takes cooperation and patience. All significant organizational shifts do. But by following these steps, you will pave the way for DevSecOps—the holy grail of modern security—to strengthen customer trust and business endurance. Turns out, working together makes things safer and more enjoyable in both the culinary arts and application security.

  • DevSecOps and Passwords: Lessening the Burden

    DevSecOps and Passwords: Lessening the Burden

    The point of DevOps is to make IT more responsive (and hopefully more stable, but we have evidence that is not always the case). The point of DevSecOps (so far) is to make security more responsive and to build security right into the stack. These are both worthy goals. As we all have pointed out repeatedly, an already overworked security team needs DevSecOps to keep up with the increased rate of change that a more responsive IT department represents.

    And yet, while we’re automating and simplifying things, the security end of DevOps is doing little for end users. Automating protection of App X is good for the App X team and good for the company, but it means little to the ultimate users of security. We all know security is a burden that users bear in the hopes of protecting the company, but no one is a fan. So maybe you didn’t have self-service password management, and now you do. Great! That helps end users. But most of us were already implementing self-service in an attempt to lift some of the load off of the security and help desk teams by the time DevOps took hold.

    Maybe you’ve implemented SSO as a result of DevOps. Again, good move! Employees spend less time remembering passwords and more time being productive. There’s less stress, too. But again, that was already well along, DevOps or not. And you know what? Employees are still making passwords they can remember, writing down passwords, re-using the same complex password, etc. To make it more difficult to hack, IT has come up with all sorts of strange rules such as, “Password digits, when summed, must be divisible by the square root of pi …” but that does little if the same password is used for LinkedIn (because it is “work-related”) and LinkedIn gets hacked again. And don’t fool yourselves, I know tech-savvy people who do this. Non-technical people are doing it a lot if techies are doing it.

    Which brings us to my suggestion: Your DevSecOps plan should include a password manager budget. There are a ton of them available, they’re cheap enough no matter which one you choose and they will generate complex passwords and then remember them for the user. Give employees password managers, train them a bit on their use, and reduce the chances that their password is the same as the one they used at pleasehackme.com. The investment is small—a few dollars per user for most managers—and choices include vaults that are local or hosted and the ability to set password-generation parameters.

    The only problem with a service-based password manager is ownership of the account after the employee leaves the company, but a policy can clearly delineate when responsibility transfers to the user and arrange for removing them from systems at the same time.

    More secure, less user hassle (true single sign-on, since they only need to know the password to the password management tool) and low cost—this is the heart of DevSecOps. And the investment is small. A bit of cash, a bit of training. What’s not to love?

  • Why Service Meshes Are Security Tools

    Why Service Meshes Are Security Tools

    Are service meshes overhyped, or do they solve a real puzzle for enterprise IT systems? Service meshes are a relatively new technology, and many people have found it challenging to fit them into predefined tooling categories. That’s because service meshes have a wide variety of functionality, from load balancing to securing traffic. But service meshes do more than securing your traffic via mTLS, and they can be very important security tools for your enterprise.

    Service meshes help organizations improve their security posture, working to both proactively prevent attacks through encryption and access control as well as to provide visibility into anomalous behavior when security incidents do happen. Service meshes can be a strong addition to organizations’ security tooling and are especially important for securing applications that have both cloud-native and legacy components.

    In the past, controlling the perimeter of the network was considered “good enough” when it came to network security. There are two problems with this: First of all, even in legacy systems getting through the firewall was often not that hard and, once in, attackers could access the entire system. Just as importantly, this approach simply does not work for distributed, cloud-native applications that don’t even have a clear perimeter to protect. A service mesh makes it possible to tighten control over traffic inside the virtual network, so even if a malicious actor gets in, its presence is easier to detect and the extent of the damage can be limited.

    Service Mesh and Security

    Here’s why services meshes should be considered security tools—and how they work to secure modern enterprise applications.

    Central Control Over Communications

    Modern engineering organizations need to give individual developers the freedom to choose what components they use in applications as well as how to manage their own workflows. At the same time, enterprises need to ensure that there are consistent ways to manage how all of the parts of an application communicate inside the app as well as with external dependencies.

    A service mesh provides a uniform interface between services. Because it’s attached as a sidecar acting as a micro-dataplane for every component within the service mesh, it can add encryption and access controls to communication to and from services, even if neither are natively supported by that service.

    Just as importantly, the service mesh can be configured and controlled centrally. Individual developers don’t have to set up encryption or configure access controls; security teams can establish organization-wide security policies and enforce them automatically with the service mesh.

    Developers get to use whatever components they need and aren’t slowed down by security considerations. Security teams can make sure encryption and access controls are configured appropriately, without depending on developers at all.

    Cross-environment Microsegmentation

    The ability to control access to different parts of the infrastructure is a key part of any organization’s security posture. But in most modern enterprises, each business unit will have applications running both on-premises and in the cloud—potentially in multiple clouds.

    With an agnostic service mesh to bridge environments, organizations can segment networks in a way that still creates a seamless experience for users and doesn’t become too complex for security teams to manage effectively.

    Inside each segment, the service mesh can be used to create attribute-based access controls (ABAC), role-based access controls (RBAC) or even next-gen access controls (NGAC). A service mesh allows organizations to tune this access control very granularly, including inside individual network segments and across different deployment environments.

    Detailed Telemetry

    In addition to providing consistent encryption and access controls, service meshes can also provide the telemetry that organizations need to identify potential security incidents and respond appropriately to anomalies.

    Because all traffic moves through the service mesh, the mesh is able to collect and display granular information about network traffic. This includes the ability to track the origin and destination of every request sent through the mesh, which is important both for security as well as for passing compliance audits.

    With a service mesh that connects both legacy and cloud-native environments, detailed traffic information is available for the entire system. Security teams can use a single dashboard to see how traffic is moving through the system and to correlate signals to users, IP addresses and content as it moves from one environment to another. Having all the information in one place reduces the risk of miscommunications or miscorrelations as traffic moves between environments, either obscuring a real security risk or raising red flags unnecessarily.

    Consistent Cross-environment Security Postures

    Most modern enterprises have a hybrid/multicloud IT system that includes legacy monoliths in data centers, cloud-native infrastructure in private clouds as well as workloads running in at least one public cloud. There are legitimate business reasons for all of these infrastructure choices, but organizations need to have a strong, consistent security posture across all of them. Service mesh technology allows organizations to connect all of the services, applications and components in the system, regardless of environment, and ensure encryption, access controls and visibility into traffic flows extend throughout the entire system.

    Conclusion

    Adding a service mesh to your security toolkit is a way to ensure consistency and compliance across the entire, heterogeneous system, no matter what kind of environments and deployment architectures you have. Ultimately, your security posture is only as strong as your most vulnerable deployment. A service mesh is the best way to ensure that every part of your infrastructure complies with your internal security policies.

  • Functional Safety in Embedded Design Starts with Code Development

    Functional Safety in Embedded Design Starts with Code Development

    With embedded software likely to become more complex, now is the time to start thinking about functional safety

    As the world has become increasingly more dependent on embedded systems in functional safety markets—such as rail, automotive, aerospace and medical—ensuring the safety of the software in those systems has become even more imperative. That assurance must begin with software development.

    As we all know, software development is the point at which many vulnerabilities are introduced, potentially leading to future performance, security and safety issues. The challenge for many embedded software developers is that they are often dealing with highly complex environments. In general, these complex environments are built using C and C++ programming languages.

    While C and C++ provide developers with the flexibility and scope for the innovation that embedded environments demand, they also introduce risk. Code can have undefined or unspecified behavior, or may not behave the same way when run on different hardware. Even the most skilled developer may make decisions that inadvertently lead to errors.

    Embedded Systems and Functional Safety: Cultural Appreciation

    There are ways to reduce software development risks. From a cultural perspective, safety and security need to be baked into the software development process, right from the very start and continuing throughout the entire DevOps life cycle. Of course, this is a practice that should be happening across all software markets, not just within embedded design.

    At the same time, there needs to be a greater focus on enforcing compliance with functional safety standards. This practice requires strategies to ensure the safety and security of systems. In some industries, such as rail and automotive, the use of these standards is mandated as part of approval and compliance processes.

    Functional Safety Standards

    Functional safety standards require performing a hazard analysis and risk assessment of the system. Based on the results, safety functions are then implemented to reduce the risk to an acceptable level. Functional safety standards set out appropriate software development and verification actions to mitigate known risks.

    Some of the main functional safety standards in use today include IEC 61508, which covers electrical, electronic and programmable electronic safety systems. First published more than 20 years ago, IEC 61508 is also the basis for several other functional safety standards including ISO 26262 for automotive, EN 50128 for rail, IEC 62304 for medical devices and ISO 25119 for agricultural machinery.

    Similar to other standards, functional safety standards do not always receive a warm reception because there is a perception that they require additional work and cost. In fact, by requiring consistent, high-quality coding practices, functional safety standards can reduce time-to-market and cost because they introduce best practice efficiencies into the development process.

    Coding Standards

    Most functional safety standards require or recommend the use of coding guidelines. For example, in the automotive industry, ISO 26262 mandates the use of coding guidelines and highlights specific areas that must be covered, such as the use of a safe language subset and naming conventions.

    Typically, a coding standard is made up of the collective knowledge of many people and organizations, such as manufacturers, consultants and industry associations. This collective knowledge is then used to provide developers with a set of rules to ensure that the code they are developing is safe, secure and compliant. Coding standards also engender better quality coding practices by making code more consistent, readable and understandable within a team.

    Depending on the project, organizations often choose to implement an external coding standard either fully or partially. They may also decide to create their own in-house coding standard based on an external standard or their own experience.

    While MISRA C and MISRA C++ were originally created for the automotive industry, the coding standards are now widely used across multiple industries. AUTOSAR C++14 Coding Guidelines were developed to address the requirements of modern C++ development environments, including autonomous vehicles and in the future will be used as the basis of a new MISRA C++ standard.

    Another popular coding standard used across multiple markets is CERT (coordinated by the CERT division of the Software Institute at Carnegie Mellon University), which focuses on security. With increasing awareness of cybersecurity risks, the use of CERT in embedded software development is likely to increase.

    Successful Implementation

    Regardless of the approach, successful implementation of coding standards depends on several factors. As there may be resistance to the implementation, teams need to be involved in the selection process of a coding standard and supporting tools. By being included in the decision process, it helps the team to understand why the requirement is critical.

    In addition, while it is possible to carry out manual code reviews against a coding standard, any project of significant size will need an automated static code analysis tool.

    Static code analysis tools can detect thousands of defects quickly and accurately, which frees up the developers to consider the implementation of the design. These tools work by both analyzing an individual developer’s code changes before they are committed and then scanning throughout the entire project as part of continuous integration (CI). For that reason, static code analyzers harmonize well within DevOps-led development environments.

    With embedded software likely to become more complex—especially against a backdrop of AI, ML and IoT—now is a good time to start thinking about putting in place an effective functional safety strategy, which includes tools such as static code analyzers and coding guidelines.

  • MuseDev Offers DevOps-Optimized Security Code Analyzer

    MuseDev Offers DevOps-Optimized Security Code Analyzer

    MuseDev today announced it has made available on GitHub under an early access program a code analysis tool dubbed Muse that is designed to surface cybersecurity issues as pull requests are made from the repository.

    Company CEO Stephen Magill said rather than waiting to discover cybersecurity issues after an application is deployed, Muse makes it easier for IT teams to consistently employ best DevSecOps practices.

    There’s general agreement DevOps teams should assume more responsibility for application security as part of any quality assurance process. However, DevOps teams have lacked access to tools that would make it easier to incorporate security analytics within the context of existing application development and deployment workflows, said Magill.

    Muse is also designed to surface cybersecurity issues in a way that makes it easier for developers to comprehend, said Magill. MuseBot automatically analyzes each pull request and delivers bug reports in GitHub as code review comments. In contrast, he noted, code analysis tools employed by cybersecurity teams tend to surface lists of vulnerabilities without providing developers with enough context to remediate or even prioritize.

    Muse is also designed to provide a faster alternative that generates results in about 20 minutes, which means DevOps teams can address issues within a workflow versus waiting for a report from a cybersecurity team, noted Magill.

    Too often code analysis tools will also generate too many false positives, he said. Muse includes a broad set of tools such as ErrorProne, Infer and Pyre for various cloud platforms that are customized and configured to reduce alert noise. Muse also provides access to an open application programming interface (API) that makes the platform fully customizable, Magill added.

    Muse is available as a GitHub app that the company is promising will be free always for open source projects and other public GitHub repositories. Analysis of private repositories is also available at no cost. A self-hosted Enterprise version available for GitHub, Bitbucket and GitLab, scheduled to be generally available by the end of the year, is also available as a private beta. MuseDev is also making available a professional services team to help organizations implement the platform.

    The company itself was spun out of Galois, a research and development firm that specializes in cybersecurity.

    In general, it can cost organizations as much as 10 times more after an application is deployed in a production environment to address cybersecurity issues. Despite widespread awareness of that issue, adoption of best DevSecOps practices within many organizations remains relatively nascent. There’s a lot of interest in DevSecOps as a goal, but few organizations have been able to put the tools that are needed to construct security workflows into the hands of DevOps teams.

    However, as more DevSecOps tools become available, chances are a lot of progress soon will be driven from the bottom up in most organizations rather than from the top down.

  • Making the Move to Edge Computing? Consider This 

    Making the Move to Edge Computing? Consider This 

    Edge computing has exciting potential, but there are certain considerations to thrive in today’s competitive landscape

    Data is king, especially in the current era of the data-driven business, where a data mindset and analytical capabilities are significant factors in determining future success. With so much data to be mined and monetized, more companies are recognizing the competitive advantages of edge computing, which can also jump-start the journey to becoming an autonomous digital enterprise. That said, a variety of security and infrastructure challenges may prevent some IT professionals from making the move, according to a recent survey by Volterra and Propeller Insights.

    Distributed models such as edge computing have always been attractive because of their ability to minimize network latency issues with large data and put essential functions closer to the technology consumer. Now, they’re even more attractive with new compute and application architectures and so many new data sources—network-connected and internet of things (IoT) devices, social media, customer engagement systems, transactional systems and systems of record—dramatically expanding the volume of data and changing the nature of the data collected. Edge computing also helps solve the traditional issues of optimizing for network capacity and performance and addresses new areas such as the localized pre-processing of all data sources (telemetry, video, mobile, etc.).

    It’s no surprise, then, that 54% of the IT leaders surveyed said they prefer edge to the cloud for operators who need to control and analyze data for local use cases, and to avoid the latency that can occur when sending edge data to public cloud-based apps. By moving certain workloads to the edge of the network instead, devices spend less time on the cloud, react faster to local changes, and operate reliably–even in extended offline periods.

    Edge computing still has its challenges and difficulties to overcome. Among them are key concerns such as a lack of resources or time for long-term upkeep of application and infrastructure, and managing distributed clusters as siloed instances rather than a single resource.

    Taking IT to the Edge – Edge Computing, That Is

    Despite the roadblocks, the value of edge computing is clear. This is why many companies are including edge computing models in their business plan. However, the performance, control and governance challenges that come with distributed models of compute, applications and data should be considered carefully beforehand.

    Innovative, data-driven companies that want to stay on the cutting edge and are planning an edge migration should develop a plan and long-term vision for their mix of data center, cloud and edge resources that consider their current and future use cases. Partnerships will also prove useful. By leveraging multi-vendor, commercial off-the-shelf solutions, enterprises can be more successful yielding value from edge computing than they would with single-vendor niche products. An ecosystem of seamlessly integrated solutions will help companies harness data and translate information into insight and actions that can optimize assets.

    As today’s enterprises seek to become more data-driven and evolve into the autonomous digital enterprises of tomorrow, it’s important to think about edge use cases as part of an overall automation strategy. Companies should consider how edge applications and distributed architectures will support them from a capacity, monitoring, deployment and service management perspective.

    Finally, edge computing’s advantages also come with the risk of security vulnerabilities if they’re not addressed from the outset, since the “attack surface” of a company’s IT estate becomes much larger. Organizations must deploy a multi-layer security approach that aligns with their edge initiatives while factoring in service-level needs to ensure assets are adequately protected.

    Edge computing has exciting potential, and the enterprises that make strategic investments and take a holistic, outlook-driven, secure approach to migration will thrive in tomorrow’s competitive landscape and years into the future.

  • How to Make DevSecOps a Reality

    How to Make DevSecOps a Reality

    DevSecOps is an increasingly popular term; however, security vulnerabilities in software continue to proliferate. 2019 saw a surge in web application breaches shining a spotlight on the fact that DevSecOps remains elusive. The latest data from the Verizon Data Breach Investigations Report (DBIR) identified that web application vulnerabilities had doubled in the last year alone.

    With the rapid pivot to all things digital in 2020, the pressure on software and applications continues to intensify. Security needs to be a fundamental part of software development in our digitally dependent world. This requires organizations to focus on more than the speed of delivery and turn their attention to the quality of software as they try to accelerate the pace of digital transformation.

    Achieving DevSecOps

    Organizations striving to achieve DevSecOps need to adopt the following steps to embed security throughout the entire software development life cycle (SDLC).

    Make Security a Priority From Day One

    Security can’t be a bolt-on at the end of the SDLC if your goal is to make DevSecOps a reality. The recent Zoom failures put security flaws in the spotlight and showcased the risks resulting from delivering innovative services without factoring in security. Every member of the team spanning product developers to technical architects to scrum specialists must consider security for it to be an intrinsic part of each stage of development.

    Achieving this transformation to DevSecOps means rethinking how to determine success. Many organizations measure it solely in terms of velocity of time to market without evaluating software quality. Developers remain reticent to incorporate security and turn attention to the quality of code. As a result, software is released more rapidly but with scant regard for the quality, resulting in many applications not being ready for mass adoption.

    One Size Doesn’t Fit All With Security

    Don’t make the mistake of approaching security as a monolith. Instead, accept that it’s wide-ranging, incorporating multiple different areas spanning authentication to access control to confidentiality to integrity to non-repudiation, to name a few. Based on this broad scope, a single approach can’t hope to address all the different facets of security.

    Teams need to rethink security and look at what it means to them and what is essential to their users. This could be keeping customers’ personal identifying information confidential and establishing the types of attacks that are most likely to occur. For example, if your product is inside a corporate file, then compromised credentials and password attacks are a significant risk while denial-of-service attacks are unlikely.

    Every member of the team needs to understand security threats and techniques, so they have enough knowledge to deal with recurring issues. Threat models can include an employee unwittingly doing something wrong to trying to protect data from government-sponsored cybercrime professionals. Focusing your training on these areas will help address the vast majority of problems and ensure applications are secure. It’s vital to view security as a science rather that than an art.

    Don’t Overcomplicate Security

    Security is viewed by many as a problem that can only be solved by highly skilled and paid consultants who specialize solely in security. While there is an absolute need for these skills when reviewing architectures and carrying out audits, there is no requirement for this level of expertise when it comes to basic security checks, such as ensuring that the latest release hasn’t changed the authentication mechanism.

    The vast majority of threat models are solved using standard static and dynamic analysis tools. Once this is accepted, you can resolve 90% of security issues through a combination of tools testers and developers. This enables security to infuse every part of the development life cycle and puts an end to the practice of being an afterthought.

    Conclusion

    Once organizations incorporate these three steps in implementing DevSecOps, they can ensure that achieving security becomes a core component of software delivery. Failure to do so will see that it remains an afterthought and security vulnerabilities will continue to grow.

  • Can NetOps and SecOps Finally Get Along?

    Can NetOps and SecOps Finally Get Along?

    For years, the very definition of NetOps and SecOps has involved friction and even contentious relationships that make their respective jobs more difficult and lessen their efficiency and effectiveness. Much of this conflict originates from having charters that are seemingly in opposition to each other. At the surface, NetOps stands for connectivity, openness, speed and capacity. In contrast, SecOps comes across as binary opponents, posting for far too many regulations with segmented connectivity and a more or less closed or impaired environment.

    The truth is, however, both groups have the same goals:

    • Ensuring business operations and agility.
    • Protecting resources.

    The network is only important in its ability to connect users, systems, applications, information or data and other resources, ensuring effective business operations and agility. The network is means to an end, and not necessarily an end to itself. In a somewhat similar way, security is also not an end, but, rather, the means to an end. Security exists to protect these same users and resources. It’s all about the users and resources being able to run business operations effectively and with the agility and flexibility necessary to give it strategic advantages. Reflecting on this perspective may help NetOps and SecOps realize that they are not so far apart from each other.

    Both NetOps and SecOps struggle with many of the same issues. Both are usually overworked and understaffed, responsible for critical components or aspects of business, face constantly changing environments and challenges and slowed by cumbersome processes and a lack of agility. Because of these things, NetOps and SecOps are largely in the same boat, sharing the same storm.

    netops secopsThe lack of agility is a particularly important issue, as new technologies and techniques are constantly being developed that enable security teams to stay ahead of—or at least keep pace with—attackers. Motivated attackers tend to be far more innovative that defenders and can use anything at their disposal to accomplish their goals. Entire cybercriminal supply chains exist to provide attackers with applications, utilities, routines and even services to conduct their campaigns. These things can and will be used against defenders.

    On the other hand, deploying a new security solution on the network is generally a long, involved, cumbersome process. Even changing solutions involves considerable effort. Sometimes the rules or process gets invented along the way, compounding the difficulties. Additions or changes to the network involve tedious review processes mostly dictated by NetOps. The NetOps team also faces some of these same difficulties in adding or changing network management or monitoring solutions.

    While a careful review is warranted, current processes are too time-consuming and involved. One significant improvement can come from NetOps and SecOps coming together with an established and codified approach for network changes or additions. Getting issues out on the table for discussion is a great start. This means more collaboration and a joint learning cycle on short- and long-term organizational objectives. Both groups need to understand and appreciate the concerns of the other and realize their common ground. Prioritizing issues and agreeing on a fundamental set will ease the overall process, reduce unwarranted fear and antagonism, and eliminate much of the inventing the process on the fly.

    An emerging approach seeks to establish a centralized deployment point for both networking and security solutions with pre-established rules agreed upon by both teams. Ideally, many of the concerns can be addressed or mitigated by hardware and software designed to enforce policies or rules, provide failover as necessary, prevent performance degradation or add to the attack surface. These can allow solutions to drop into the network while offering guarantees of performance or availability.

    Streamlining deployment of shared management will result in much-needed agility and also boost efficiency and overall effectiveness. It will also lessen the typical tensions or outright opposition.

    NetOps and SecOps are much closer to each other than either realizes. Their shared guardianship of users and resources can benefit from joint discussions, plans, tools and policies. Not only can they better accomplish their own charters of connecting and protecting while providing agility and flexibility, but they also can become far more efficient with their operations. They need each other, and their organizations need the vital contributions from both. As typically said in security jargon, “A chain is only as strong as its weakest link.” The new paradigm of security-driven networking is about preventing weak links through the collaboration and synergy between NetOps and SecOps.

  • ShiftLeft Brings Security Workflows to DevOps Processes

    ShiftLeft Brings Security Workflows to DevOps Processes

    ShiftLeft has updated its NextGen Static Analysis (NG SAST) tool to include workflows that are purpose-built for developers.

    Company CEO Manish Gupta said the security workflows are designed to make it easier for DevOps teams to incorporate them within their application development and deployment processes. In fact, a survey of more than 165 developers, application security and DevOps professionals conducted by ShiftLeft finds 89% of respondents said the current disconnect between developers and cybersecurity teams is the biggest inhibitor of productivity.

    The issue with rival static analysis tools is they were not designed from the ground up to incorporated into a DevOps process, said Gupta. As a result, he noted, security workflows are managed around application development processes rather than being incorporated within them.

    The survey finds that most IT teams are performing security scans too late in the software development life cycle (90%) and when they do discover an issue they often lack any remediation guidance (88%).

    Most existing cybersecurity processes can’t keep pace with the rate at which applications are being deployed. The survey finds nearly 70% of software development organizations are releasing multiple times per month or more, with 18% releasing at least daily.

    Gupta said NG SAST overcomes that issue by automating code analysis during every pull/merge request. That approach enables developers to address security issues much the same way they do any other bug. Rather than having to wait on a report from an application security team, developers can remediate a security issue from within their development environment log before it ever shows up in a report, he said.

    Productivity and application quality improves because vulnerabilities get fixed faster while the code at issues is still uppermost in the mind of the developer, Gupta said.

    DevOps teams can also create build rules that accept or deny merges based on how many security vulnerabilities there are, he added. That capability prevents security flaws from become too deeply embedded within the build process before they can be more easily remediated.

    Gupta said security scans are also run locally where applications are deployed, which means source code never has to leave the organization. That approach also eliminates the need for network and firewall architecture updates to access an external scanning service. It also reduces bottlenecks inside organizations that might need to do as many as 20 scans per hour, he noted.

    Overall, Gupta said it’s not uncommon to see developer productivity increase by a factor of 40 because ShiftLeft NG SAST enables scans to be run instantly. The days when developers took a coffee break while waiting for a security scan to run are now over, he said.

    Of course, the level of productivity gain for development teams that might be gained by embedding static analysis within the application development process will vary widely. However, given the fact that developers outnumber cybersecurity professionals by several orders of magnitude, it’s also readily apparent dedicated application security teams can’t keep up. Unless organizations give developers the security tools they need, any ambitions an organization may have about implementing best DevSecOps processes will remain largely a pipe dream.