devopsy.kinsta.cloud

Tag: cyber security

  • OpenAPI Specification: Perception vs. Reality

    OpenAPI Specification: Perception vs. Reality

    The OpenAPI Specification (OAS) (formerly known as the Swagger specification) provides a way to describe and document REST APIs and their components. It includes details on endpoints, their operations, parameters needed for the operations, expected responses for every operation, authentication methods and even annotations. OAS is an easy format to learn and read, and can be understood by both humans and machines. As you might imagine, this kind of “accessible” documentation is useful and beneficial in a number of different use cases for both development and security teams.

    Developer Relationships With OAS

    For developers, OAS can be used to generate documentation for APIs. Proper documentation can help other developers figure out how best to integrate and use these APIs with their own application.

    Even so, many developers have a love/hate relationship with OAS. Let’s face it, documenting is a far cry from developing. Although it is easy to learn, the actual act of documenting is tedious, manual and time consuming. Frankly, it’s probably one of the least glamorous parts of a developer’s job, and, therefore, many developers only do the absolute minimum. As a result, OAS can be incomplete or, in some cases, missing entirely. Not to mention, when the API is updated, how often is the OAS updated, too?

    In the case of incomplete or nonexistent documentation, developers will muddle through with trial and error, even though this can slow down the development process.

    If out-of-date OAS proves an annoyance for dev teams, what’s the impact on security?

    Security’s Relationship With OAS

    OAS can be consumed by both humans and machines, and both are critical for security’s use of OAS.

    OAS helps security teams (humans) become aware that the API exists, since its documentation is often part of the CI/CD process.

    By examining an OAS file, a security team can understand what the API is supposed to do and, from that, determine if it conforms to or violates the organization’s security policy. As an example, security teams might use the OAS to make sure that authentication and authorization are being implemented correctly, and that sensitive data, like PII, is not being exposed.

    Security teams might also deploy tools (machines) that use the OAS to enforce policy based on what’s in the documentation. As an example, the OAS may specify that, for a particular parameter, a string should be expected; it should be no more than four characters and it should contain only letters and numbers with no special characters. By validating input based on what is defined in the OAS, security tools can check that the API does what developers intend it to do.

    This plan sounds great on paper, but …

    Perception versus Reality

    Imagine a perfect world, in which every API is well-documented as part of the development process. As that API makes its way through the development pipeline, it does so hand-in-hand with an associated OAS. At the appropriate time, before production, security is made aware of the API and the OAS, the team evaluates the details, validates that the API matches policy, gives the thumbs up and the API goes into production. Security and development teams live in harmony and everyone is happy.

    We don’t live in a perfect world. Instead, we must deal with questions such as:

    • Does the OAS exist? In the most extreme cases, the OAS doesn’t even exist. It was never created as part of the development process, so it can’t be used for any sort of awareness. These misses happen more often than you think, giving rise to the problem known as shadow APIs. These APIs slip through the cracks, and make it into production with no documentation at all. While you might be saying to yourself, “Our company would never let this happen!” you should also consider that numerous APIs are stood up by development teams as a test, as part of a beta or as a quick-and-dirty way to get something done. There are more of them than you think, and these shadow APIs create unrealized risk.
    • Is the OAS complete? In slightly less-scary territory, let’s consider an incomplete OAS. You might be saying to yourself, “We have a top-notch development team, well-defined development processes and strict policies around documentation. No API makes it into production without an OAS!” Perhaps, but the devil is in the details, and those details are often missed. I’ve worked with countless customers who have happily and confidently produced an OAS in which critical details don’t match the reality of the API. Sometimes they’re not complete. Sometimes they’re missing all together. The industry calls these missing details shadow endpoints. Yes, someone did produce an OAS, and security was aware of the API, but a lot of critical detail is missing.
    • Is it being kept up-to-date? Development cycles seem to be moving faster and faster, and as documentation is one of the least glamorous parts of a developer’s job, updates can be missed, dismissed or, at the very least, lag behind. We commonly see multiple versions of an API, and the OAS does not reflect the new capabilities of the latest version.

    While a non-existent or outdated OAS presents a modest concern for API visibility, it creates a substantial concern when trying to serve as the foundation for API security.

    You take a huge risk if you depend solely on OAS for security. More often than not, an OAS is not accurate, lacks critical details and is only as useful as the data you feed into it. Gaps, including shadow APIs, leave out critical details, making enforcement impractical.

    The inaccuracy of OAS leaves customers with two choices. You can either enforce security policies based on strict adherence, and risk blocking legitimate traffic, or you can enforce based on loose adherence and risk letting attacks through. In either scenario, your organization is unduly vulnerable, and significantly less secure than your dev teams intended or your security teams would like.

    OAS is Only a Starting Point

    OAS provides a great starting point for documenting your APIs. Don’t make the mistake, however, of basing your API security strategy on what’s in your OAS. It’s simply not accurate enough. Taking that approach will leave your company’s vital data and services at the mercy of API attackers who will quickly know more about your APIs and what they expose than your OAS does.

  • A Pragmatic Approach to DevSecOps

    A Pragmatic Approach to DevSecOps

    In response to market and competitive forces, many companies are using DevSecOps to develop higher quality and more secure software. Whether that software is their own product or is a component of their product, quality – and especially security – have become required rather than optional. To accommodate the security requirements, some companies have adopted DecSecOps overlays to their software development process that can, and has, caused significant disruption.

    Barriers to DevSecOps Adoption

    The main barrier to the transition from DevOps to DevSecOps is organizational rather than technical. Many companies are already employing special security teams tasked with ensuring applications are secure and that policies are being followed. However, they tend to act as gatekeepers to the release process – nothing gets released without security testing. This approach is prone to be “too little, too late,” as the security team is usually involved near the end of the development life cycle. Attempts to “test in” security rarely succeeds. Security needs to be built in from the start; “shifted left” so that security is fully integrated into the process from the start. Let’s break down these barriers:

    • Lack of motivation and awareness:  There’s a lack of awareness about security issues, and about the risks and impacts security vulnerabilities pose to the organization in terms of liability and reputation. Vulnerability statistics make it clear that many companies are still not taking security seriously enough. This indifference remains, even when 63% of companies had, or nearly had, vital data breaches in 2019 and each breach cost an average of $3.9 million to deal with.
    • Distrust: Lack of trust between teams is expected in most organizations, but it’s particularly problematic between software developers and security teams. Developers view security as impeding their success, and security teams view developers as incapable of delivering secure software.
    • Poor Perception: The prevailing view of security is that it’s difficult to implement and somebody else’s problem. If security teams are solely responsible for security, then it’s easy for developers to delegate to them. Companies often think that security can be tested into the product at the end of development – with disastrous results. Vulnerabilities discovered at this late stage are more difficult to debug, with subsequent impacts on time-to-market, budgets, product quality and reputation.
    • Gatekeeping: The security team sometimes acts as gatekeepers of release candidates, which is a source of friction between developers, testers and security experts. Placing security as a last, QA-like step before delivering a release is too little, too late. Developers also don’t like other teams imposing restrictions on their work, which is an issue when trying to put security controls, like secure coding practices, in place.
    • Lack of integration: Without integrating security practices and tools through the entire development process, security improvement initiatives have trouble getting off the ground. In fact, the key tenet of DevSecOps is to integrate security practices into each phase of development.

    These barriers might seem daunting, but it’s not unlike other corporate cultural shifts. Security teams need to delegate aspects of security to development teams and integrate secure practices as early as they can in their work. Developers need training and understanding of how critical security is to their work. Developers already have an appreciation for safety and quality, but lack some of the basics of good security practices.

    It doesn’t need to be this way. However, removing these barriers won’t happen overnight, so a practical and gradual approach to improving security is needed.

    Easing Your Way into DevSecOps

    Transitioning to a more secure software development process across an organization rarely works when done with a “big bang” approach. There’s often lack of buy-in from the teams, and general resistance to change when new approaches haven’t proven themselves. The cultural barriers to adoption remain, and the initiative fails. As with any large task, it makes sense to start small; to learn and adapt before expanding to more teams. The move from DevOps to DevSecOps should be organic.

    Start Small

    The alternative to the doomed “big bang” approach is to start with a small, motivated team, where it’s possible to implement new practices from the very beginning of a project. By keeping the scope, and thus, the technical and business risk, of the project smaller, it is possible to allow time for learning and adjustments along the way. Think of this as an incubator project, where the results are analyzed and used to evaluate gains, losses, what went right and what went wrong. This team can learn, and then teach the larger organization what works and what doesn’t. Importantly, they set the standard for how to approach DevSecOps, and kick off the organic growth needed for a smoother transition.

    Starting small extends to the use of new tools, as well. It’s one thing for a small team to adopt new technologies, but they can be quickly overwhelmed. Static application security testing (SAST) tools can produce a lot of information. It’s important that initial projects concentrate on high impact, high probability vulnerabilities, first and foremost. It’s easy to get bogged down in the details, and discipline is needed to focus on the highest impact, and to get the most ROI out of new tools.

    Start at the Beginning (Or as Early as you Can)

    This is where “shift left” plays an important role in the transition to DevSecOps. A small team can introduce new techniques without a large initial impact on productivity. They can also start integrating security from the beginning, right at the concept phase of development. They can introduce new tools, and become proficient at using them. It’s at these early stages where the payoff is the greatest. Finding and fixing possible vulnerabilities, and adopting more secure design and coding practices, greatly reduces the downstream impact. It’s not hard to justify the effort, when security attacks and data breaches in production systems can cost millions in fixes, downtime and reputation.

    Measure Success

    The interesting thing about measuring DevSecOps success is looking at what isn’t there; security vulnerabilities and potential software weaknesses. To understand how well a new DevSecOps transition is working, it’s important to have a baseline of vulnerabilities that exist in your other applications. For example, how many vulnerabilities were discovered during security testing? How many vulnerabilities made it into shipping products? If these statistics are known, then it’s a case of measuring how well the new project does versus the baseline performance.

    Other metrics are important, too, such as measuring the number of vulnerabilities detected, identifying those that are true risks and those that were removed through corrective action. SAST tools provide information on a per-build basis, so it is possible to look at trends over time. You can evaluate the DevSecOps process in terms of vulnerability trends over time; are they converging to a goal? How quickly is the convergence?

    The ultimate measurement of success is a more secure product and, ideally, security testing at the later stages of development should find fewer vulnerabilities than in the past. After building in security and starting at the beginning with a shift-left approach, vulnerabilities are caught sooner and removed more quickly.

    Start your DevSecOps Transition

    The critical time to detect new security vulnerabilities is as soon as developers write new code (or test cases) before it’s submitted to a build or software control system. It’s also critical that tools work in your favorite development environment (be that VI, Emacs, Microsoft VS Code or Visual Studio, or any of a number of Eclipse-based environments). It’s at this point where SAST tools shift security improvement via automation to the earliest point in the development cycle. Finding and fixing vulnerabilities here is less risky, cheaper and easier.

    Equally critical is establishing an initial baseline inventory of your third-party software assets, whether that is open source, reused internal code from other projects and/or third-party commercial software. This is done at the very beginning of the project, about as shift left as it gets! Software composition analysis (SCA) is critical throughout the development process since the open source and third-party software that you depend on is likely to have updates and introduce new security threats over time (including after you release the product).

    Early adoption of SAST and SCA tools can have many benefits as part of your DevSecOps adoption. These tools used in conjunction with a security “built in” approach make this transition easier:

    • Improve security awareness by exposing vulnerabilities in existing code, third party software and newly developed code. SAST tools provide all the necessary information to fix potential vulnerabilities, but also provide an explanation of the severity and risk. Developers get more experience with the types of software weaknesses that lead to vulnerabilities, and learn to avoid them.
    • Illustrate ROI by measuring success, and have a goal in mind. Eliminating just one serious vulnerability justifies much of the investment. However, communicating this ROI is important, and needs to be put in the proper context of how costly and risky vulnerabilities are once a product is released.
    • Remove gatekeeping so that developers and the security team are working together. Security teams provide the security controls that developers need to follow with a “trust, then check” approach. Developers learn more about secure practices over time, and integrate that knowledge into their existing workflow. In the end, there is no security team gate at release, and all members of the team know and understand the state of the product.
    • Integrate security practices into software development gradually, starting with a small team and small project. As experience is gained, these teams train the rest of the organization on best practices.

    DevSecOps From the Ground Up

    DevSecOps is a way to build security into an application, and the transition from an existing CI/CD and DevOps process is made easier with the right approach. Successful transition depends on breaking down the resistance to security practices that exist in many organizations. A “start small and start early” approach is recommended where new techniques, processes and tools, such as SAST and SCA, can be integrated with less downtime and cost.

    Most importantly, you need to decide what the success factors are. Measuring success and the ROI of the effort is needed to grow DevSecOps organically within the organization. Tools and automation provide the data needed to show progress, but communicating the ROI needs to be done in business terms. In the end, success results in a more secure product, and reduces your company’s exposure to data breaches and cyberattacks.

  • How Managed Detection and Response (MDR) Solutions Benefit DevOps

    How Managed Detection and Response (MDR) Solutions Benefit DevOps

    Managed Detection and Response (MDR), a relative newcomer in the cybersecurity realm, is starting to have a noticeable impact on enterprises seeking to better secure their operations. Research giant Gartner notes that, “By 2025, 50% of organizations will be using MDR services for threat monitoring, detection and response functions that offer threat containment capabilities.” Despite rising adoption rates, though, much confusion remains about MDR and how it should fit into enterprise IT.

    MDR is typically defined as an outsourced security service that enables organizations to better detect malicious activity over the network. MDR is usually sold as a service, and vendors offer tools and technologies that integrate into a business’s IT to detect and mitigate network intrusions, malware attacks, attempted data theft and other malicious threats. MDR can be a powerful ally in the quest to contain cyberattacks, but only if deployed correctly and leveraged properly.

    Enterprise Benefits

    MDR offers obvious benefits for enterprises, but there’s enormous potential when MDR is integrated with DevOps. Many organizations are turning to DevSecOps methodologies to build cybersecurity into their development and deployment pipelines, and MDR can help.

    “One challenge is that DevSecOps is a term that is poorly defined in most cases, and misunderstood in many others,” said Dave Martin, senior director, product management – threat response at Open Systems. “Some people think of DevSecOps as an extension of a quality assurance department, which means that cybersecurity is mostly an afterthought, and not part of the development cycle. MDR, at least how we do it at Open Systems, brings forth a full-time security operations layer, which includes a security analyst, that can become part of the DevOps team,” Martin said. 

    Martin makes an interesting point. As more organizations attempt to implement DevSecOps, knowledge, along with action, are lacking. MDR has the potential to supplement knowledge and insight into the security posture of the code being generated. Many organizations leave cybersecurity to the network or operations teams, expecting endpoint or network security tools alone to contain threats. However, many threats in the wild may leverage older code, or target unpatched applications. MDR can enable DevOps teams to get ahead of the latest threats by keeping developers informed about evolving threats and vulnerabilities, as well as incorporating tools for continuous cybersecurity into the development and deployment pipelines. One of the core concepts of MDR is providing access to experts that can take action to mitigate an attack. This is an important consideration, according to the Enterprise Strategy Group, which reports that 51% of survey respondents face a problematic shortage of skills in the area of cybersecurity.

    What’s more, MDR becomes a tool to secure the DevOps environment, as well as a tool for developers to make code more secure. “It is critical to find advanced threats, ones that may have bypassed existing security controls, before those threats impact DevOps, yet people need to be made aware of those threats so they are not mistakenly included in the development pipeline,” said Martin.

    Choosing an MDR Provider

    With so many players in the MDR space, choosing a provider that fits into a DevOps and enterprise strategy can be daunting. According to Reports and Data, the global MDR market is expected to grow at a CAGR of 30.4% until it reaches $4.6 billion by 2026. Today, providers number in the dozens, and while many claim they have “complete” offerings, they may not consider the needs of DevSecOps along with traditional network operations concerns.

    There are some important considerations when choosing an MDR platform. For example, visibility of the attack surface is a critical concern. If an MDR provider does not have visibility into all potential attack surfaces, breaches and compromises may still occur. Also, adopters should be keenly aware of how false positives are contained, as well as the level of alert activity. Many cybersecurity solutions can introduce alert fatigue and obscure effectiveness. Automation should be a key part of any MDR solution, as it can help to categorize threats, initiate responses and identify the latest threat trends without human interaction. 

    “MDR should tear down many of the cybersecurity silos that businesses have today, and bring the various pieces of IT together into a unified cybersecurity sensitive culture,” said Martin.

    Ultimately, MDR is about people, processes and technology, and should bring these elements together to ensure success in the ongoing battle against cybercriminals. 

  • RiskRecon Invents Ground-Breaking Asset Risk Valuation Algorithms, Transforming How Enterprises Manage Third-Party Cyber Risk

    New algorithms solve the cyber risk equation by automatically determining the risk value of computer systems, enabling precise cyber risk assessment and action

    Salt Lake City, Utah — October 15,  2018 — RiskRecon, the world’s leading platform provider for easily understanding and acting on third-party cyber risk, announced its ground-breaking asset valuation algorithms that automatically determine the inherent risk value of any Internet-facing system. Automatically determining asset value is critical to managing cyber risk because it enables organizations to easily create action plans focused on addressing risk.

    “Risk professionals spend too much time analyzing mountains of issues to determine the risk relevance,” explained Kelly White, Co-Founder and CEO of RiskRecon. “RiskRecon automatically contextualizes every issue with issue severity and asset value that enables professionals to easily identify risk priorities and needed action.”

    RiskRecon visually summarizes issue risk priority within a “Risk Prioritization Matrix,” showing each issue within the context of issue severity and asset risk value. Summarizing the risk priority of 3,000,000 issues existing in commercial Internet-facing systems reveals that only 0.12% are critical severity issues in high-value assets. “The vast majority of risk resides in less than 6% of total issues,” explained White. “RiskRecon enables you to easily identify the issues of risk that matter and, just as importantly, identify the issues that don’t.”

    Jack Jones, Chairman of the FAIR Institute and Co-founder of RiskLens, noted that: “Far too much energy in information security is wasted on resolving issues that don’t matter. As the FAIR model promotes, effective risk management requires understanding the probable frequency and magnitude of loss; that depends on understanding asset value. I am really pleased to see RiskRecon bring the ability to automatically determine asset value to market.”

    RiskRecon’s asset valuation algorithms automatically assign a value to cyber assets such as systems, domains, and networks. The algorithms also tag each asset with value indicators, including the system’s functionality and the data types it collects; these indicators enable risk professionals to immediately understand any asset’s value.

    Deployed to third-party risk management, RiskRecon’s automated risk assessments provide the most precise visibility into vendor cyber risk performance, enabling dramatically better third-party risk outcomes with much greater efficiency.

    RiskRecon customers use this capability to better solve third-party cyber risk, enabling them to identify and act on the vendors and issues that expose them to the greatest risk. Organizations also leverage RiskRecon to better understand their own risk surface and exposures.

    About RiskRecon

    RiskRecon is the only continuous vendor monitoring solution that delivers risk-prioritized action plans custom-tuned to match your risk priorities, providing the world’s easiest path to understanding and acting on third-party cyber risk. Partner with RiskRecon to build your scalable, third-party risk management program to realize dramatically better risk outcomes. To learn more about RiskRecon’s approach, request a demo or visit the website at www.riskrecon.com.

    Connect with RiskRecon:

    LinkedIn: https://www.linkedin.com/company/riskrecon/

  • It’s Time to Couple Security, Business Leadership

    It’s Time to Couple Security, Business Leadership

    With the RSA Conference next week, the biggest conference of the year when it comes to enterprise security management, now is an ideal time to look at how IT and security leaders keep security efforts aligned with business objectives.

    There’s a reason why attaining adequate and consistent information security is one of the most challenging aspects of technology management today. The business needs to push IT as far as it can to compete. The CIO and business leaders need to provide the applications and access to data to help people be as productive as quickly as they can be, and get the business services and features to market that customers seek. The role of security, however, is to make sure all of this is done in a reasonably and adequately secured fashion.

    This obviously causes a natural friction between the objectives of the business and the needs of the security team.

    When this friction between the business and security isn’t properly managed, a misalignment arises—and it’s costly.

    It means without executive leadership, security efforts can be sidetracked by the business, appropriate budgets aren’t put into place and overall security and governance efforts are weak. And a lack of healthy dialogue between the security leadership and business leadership will leave misconceptions about the level of security in place.

    The Case for Security Leadership

    A few years ago a Global Information Security Survey conducted by CSO online and PricewaterhouseCoopers found that 43 percent of organizations surveyed believed that their organizations where information security “leaders.” However, when screened for common attributes of what might be considered common among information security front-runners, only 5 percent appeared to actually have mature security programs.

    That’s quite a disparity.

    And when we have this much of a disconnect between security and leadership, proactive security investments don’t get funded, there’s no consistent security policy enforced across the organization and executives don’t understand the real types of business technology risks they face.

    Fortunately, that is starting to change. According to PwC’s most recent “Global State of Information Security Survey 2016,” boards are today more involved in security budget, strategy, policy and other aspects of information security management.

    In my interviews with CISOs and CIOs over the years, it’s hard to find anyone who doesn’t agree that security and business alignment requires healthy and open lines of communication. And this is one of the first places nearly everyone recommends enterprises start if they are not aligned.

    Executive leadership is critical when it comes to successfully aligning security and business objectives. This is because information security teams need to make unpopular decisions. They may have to slow down the release of a new service (especially if the only security review came at the end of the development pipeline), require more automated tests or suggest other ways of doing things that may mitigate unnecessary risk.

    But let’s face it, without executive backing, these efforts will get run over by the momentum of the business. Does this mean everything security suggests it should get? Of course not, but that’s where good communication comes in: At least business leaders come to understand how technical risks translate into business risk.

    What is undeniable is that enterprises with security programs that are aligned with their business and the risk appetite of their organization are going to have more successful in their risk management efforts than those who wing these things.

    In an Accenture 2014 report, “The Cyber Security Leap: From Laggard to Leader,” Accenture concluded that “as part of establishing better governance and controls, CISOs should foster a strong working relationship with their boards and create greater visibility into business processes. They need to educate and collaborate to successfully articulate and prioritize business risk, including insider-related risks. The strategy should be continually assessed to evolve with the organization’s posture and get the best use out of resources.” I agree completely. And if more organizations conducted themselves in such a way, there’d be a much smaller gap between security teams and their organization’s board of directors, as well as a tighter separation between security perception and security reality.

  • Illumio Introduces Adaptive User Segmentation as the Newest Weapon in the Battle to Reduce Cyber Attack Surface

    Illumio’s Adaptive User Segmentation capabilities dynamically integrate Microsoft’s Active Directory entitlements for hundreds of millions of users, dramatically expanding the reach of the Adaptive Security Platform
    SUNNYVALE, Calif.—February 17, 2016—Illumio today announced it has extended the capabilities of its industry-leading Adaptive Security Platform (ASP)Ô through integration with Microsoft’s Active Directory groups. The new capability, known as Adaptive User Segmentation, dynamically calculates and provisions connectivity rules based on user identity to prevent unauthorized communications with, and access to, any Illumio-protected applications. Illumio ASP now can govern how hundreds of millions of users connect to applications across data centers, clouds or hybrid-cloud compute environments.
    Adaptive User Segmentation is the latest step in Illumio’s core mission to secure data anywhere it resides:
    ·      When Illumio launched in October 2014, it introduced a complete range of adaptive segmentation models to reduce the attack surface, from environmental separation to micro-segmentation. It also introduced “MRI-like” visualizations of data center and cloud environments, as well as policy-driven transport layer encryption.
    ·      During RSA 2015, the company introduced its nano-segmentation capability, which provides process-level segmentation among both physical servers and virtual machines and reduces the surface area of server-to-server communications by over 99 percent. Illumio also extended its policy-driven segmentation model to incorporate F5 Local Traffic Manager and Application Firewall Modules.
    ·      Later in the year, Illumio announced partnerships with Docker and Mesosphere to extend adaptive security capabilities to fast-growing Linux container deployments.
    Illumio’s Adaptive User Segmentation extends to all of these environments and delivers the most meaningful reduction in the cyber attack surface area in computing history. The company has fused governance of both workload-to-workload communications and user-to-workload communications through this technology breakthrough, strengthening the traditional entitlement model in a way never possible before today. According to statcounter.com, Windows 7—the target OS for VDI desktops/laptops connecting to the data center—accounts for just under 50 percent of all desktop operating systems in operation.
    Today, users within an organization can see and connect to most, if not all, applications within the data center or cloud environment, regardless of their Active Directory entitlements. Given heightened challenges to deliver trust and security, relying on central systems of record like Active Directory to ensure users only have access to the appropriate assets is no longer sufficient. The breaches that occurred in the past few years in large enterprises and government agencies underscore that entitlements and authentication alone are unable to provide the protection required by high-value applications and data.
    Leveraging the Illumio ASP approach of writing and delivering a dynamic policy using a whitelist model, the integration of Illumio ASP and Active Directory allows an organization to ensure that only the correct users can connect to the appropriate workloads and applications in the data center, public cloud, private cloud or hybrid compute environment.
    “Illumio’s mission since our founding has been to help our customers regain control over their applications and data,” said Andrew Rubin, co-founder and chief executive officer of Illumio. “With the introduction of Adaptive User Segmentation, Illumio once again is dramatically reducing computing attack surface through dynamic, policy-driven enforcement that allows users to only connect to the data center and cloud compute they are entitled to access.”
    “Illumio’s new capabilities will resonate with security professionals assessing their security posture,” said Jon Oltsik, senior principal analyst, Enterprise Strategy Group. “Security leaders must deal with both sides of the user/data center equation and are well served to do it together rather than separately.”
    About Illumio
    Illumio delivers adaptive security for every computing environment, protecting the 80 percent of data center and cloud traffic missed by the perimeter. The company’s Adaptive Security Platform™ visualizes application traffic and delivers continuous, scalable, and dynamic policy and enforcement to every bare-metal server, VM, container, and VDI within data centers and public clouds. Using Illumio, enterprises such as Morgan Stanley, Plantronics, NTT, King Entertainment, NetSuite, and Creative Artists Agency have achieved secure application and cloud migration, environmental segmentation, compliance, and high-value application protection from breaches and threats with no changes to applications or infrastructure. For more information, visit www.illumio.com or follow @Illumio.
    ———————————————-
    Amber Rowland