Posts

Why All The Emphasis On Insider Threats? Three Reasons:

Centrify Logo1. Insider security risks are more prevalent and potentially more damaging.

According to a study conducted by the Ponemon Institute, 34% of data breaches in the U.K., come from malicious activity, including criminal insiders, and 37% of breaches come from employee negligence. A previous Ponemon study indicated that a third of malicious attacks come from criminal insiders. Further, a Forrester study revealed that 75% of data breaches were caused by insiders, most often due to employee negligence or failure to follow policies. The most-often cited incidents were lost devices, inadvertent misuse of sensitive information and intentional theft of data by employees. The impact of data breaches and downtime, whether caused by insider malice or negligence, can cripple an organization, exposing it to lost revenue, significant brand damage and increasingly onerous regulatory fines and penalties.

2. User identity “blind spots” are causing audit failures.

Many organizations are failing audits because of blind spots in their identity infrastructures. Blind spots can occur when identities and entitlements are managed in disparate silos or on local servers rather than centrally. For example, one of the biggest identity challenges for companies — and a major cause of failed audits — is a lack of visibility into local administrator accounts on Windows. This is akin to the root account on a Linux/Unix system. Failed audits can be particularly damaging in today’s environment, in which regulations related to data loss and data protection are becoming more rigorous around the world. Companies that conduct business globally have to be in compliance with a wide range of rules and regulations to satisfy audit requirements.

As such, organizations must be able to provide proof that users who have access to certain servers and applications are actually authorised users. They must also be able to deliver an auditable trail of what each user has done within the server. These requirements mean organizational policies need to apply the principle of “least privilege access,” whereby users log in as themselves and have only those privileges needed to do their jobs. If they need to have their privilege elevated for some reason, that is an explicit action.

3. Organizational complexity is posing a growing challenge.

Managing employee identity used to be relatively easy: A user was typically sitting at a desktop with a single machine connected to an enterprise application through a single wire. Ah, but things have changed. Users are now mobile and using a wide range of devices, some of which may be unsanctioned or undocumented personal devices. And mobility is only one aspect of the heightened complexity. IT infrastructures are increasingly diverse and heterogeneous, with multiple silos defined by departments, applications, operating systems or other characteristics that set them apart from one another. The proliferation of virtualization and cloud services adds additional layers of complexity to the IT environment. Without a solution to unify user identities, organizations face the prospect of having too many identities, thus raising too many identity-related risks — including data loss, data breaches, application downtime, failed audits and an inability to identify and rectify internal security problems before they escalate.

Savvy IT and security managers are recognizing that the most cost-efficient and effective way to address these challenges is to incorporate a solution that provides insiders with a unified identity across all platforms. By linking access privileges and activities to specific individuals, the IT organization can establish the control needed to minimize security risks, along with the visibility required to achieve compliance.

© 2013 Centrify Top 3 Reasons to Give Insiders a Unified Identity. 

Centrify is a PathMaker Group partner providing advanced privileged access management, enterprise mobility management, cloud-based access controls worldwide.  The Centrify Identity Service provides a SaaS product that includes SSO, multi-factor authentication, enterprise mobility management and seamless application integration.  The Centrify Privilege Service provides simple cloud-based control of all privileged accounts and provides extremely detailed session monitoring, logging and reporting capabilities.  The Centrify Server Suite provides the ability to leverage Active Directory as the source of privilege and access management across your Unix, Linux and Windows server infrastructure. Centrify is a Leader in The Forrester Wave, Q3 2016.

 

With today’s increasing Mobile Enterprise Security Threats, do you have a strategy to mitigate the risk on your Corporate Network?

Corporations are increasingly utilizing mobile enterprise systems to meet their business objectives, allowing mobile devices such as smart phones and tablets to access critical applications on their corporate network.  These devices provide advanced technologies over traditional desktop clients, such as: information sharing, access from anywhere at any time, data sensors, location, etc. But what makes these mobile devices desirable, by their very nature, also poses a new set of security challenges.  Reports by research agencies in recent years show an alarming trend in mobile security threats listing as top concerns: Android malware attacks, and for the IOS platform issues with enterprise provisioning abuse and older OS versions.

These trends highlight the need for corporations to start taking seriously a mobile security strategy at the same level to which cyber criminals are planning future attacks. A mobile security strategy might involve adopting certain Mobile Security Guidelines as published by standards organizations (NIST) and Mobile OWASP project. See the references at the end of this document:

The following guidelines are a subset of Mobile Security Guidelines I pulled from various published sources with most coming from NIST. It is by no means a comprehensive list, however they can be considered as a starting point or additional considerations for an existing mobile security strategy.

1 – Understand the Mobile Enterprise Architecture

You should start with understanding and diagramming the flow from mobile application to business applications running on the back-end application server. This is a great starting point and should be done at the beginning stages, as most of the security guidelines will depend on what is known about the architecture.

  1. Is the mobile application a native application or mobile web application? Is it a cross-platform mobile application?
  2. Does the mobile application use middleware to get to the back-end API, or does it connect directly to a back-end Restful based Web Service?
  3. Does the mobile application connect to an API gateway?

2 – Diagram the network topology of how the mobile devices connect

Is the mobile device connecting to the business application servers over the cellular network or internally through a private WiFi network, or both? Does it go through a proxy or firewall? This type of information will aid in developing security requirements; help with establishing a QA security test bed and monitoring capability.

3 – Develop Mobile Application Security Requirements

At a high level, a security function must protect against unauthorized access and in many cases protect privacy and sensitive data. In most cases, building security into mobile applications is not at the top of the mind-set in the software development process. As such, these requirements should be gathered as soon as possible in the Software Development Life Cycle (SDLC). It has been my personal experience in many cases that you have to work with application software developers in adopting best security practices. So the sooner you can get that dialogue going the better. Security objectives to consider are:  Confidentiality, integrity, and availability. Can the mobile OS platform provide the security services required? How sensitive is the data you are trying to protect. Should the data be encrypted in transit, and in storage? Do you need to consider data-in-motion protection technologies?  Should an Identity and Access Management (IDAM) solution be architected as part of the mobile enterprise system? Should it include a Single Sign On functionality (SSO)? Should there be multi-factor authentication, role based or fine-grained access control? Is Federation required? Should the code be obfuscated to prevent reverse engineering?

4 – Incorporate a Mobile Device Security Policy

What types of mobile devices should be allowed to access the organization’s critical assets. Should you allow personal mobile devices, Bring Your Own Devices (BYOD’s) or consider only organization-issued or certified mobile devices to access certain resources? Should you enforce tiers of access? Centralized mobile device management technologies are a growing solution for controlling the use of both organization-issued and BYOD’s by enterprise users. These technologies can remotely wipe the data or lock the password from a mobile device that has been lost or stolen. Should Enterprises consider anti malware software and OS upgrades to become certified mobiles on the network? To reduce high risk mobile devices, consider technologies that can detect and ban mobile devices that are jail broken or rooted, as these can pose the greatest risk of being compromised by hackers.

5 – Application Security Testing

According to a study performed by The Ponemon Institute, nearly 40% of 400 companies surveyed were not scanning their applications for security vulnerabilities, leaving the door wide open for cyber-attacks. This highlights the urgency for security teams to put together some sort of security vetting process to identify security vulnerabilities and validate security requirements as part of an ongoing QA security testing function. Scanning application technologies typically conduct two types of scanning methods: Static Application Security Testing (SAST) which analyzes the source code and Dynamic Application Security Testing (DAST), which sends modified HTTP requests to a running web application to exploit the application vulnerabilities. As the QA scanning process develops, it can be automated and injected into the software build process to detect security issues in the early phases of the SDLC.

6 – System Threat Model, Risk Management Process

What will typically come out of the application scanning process will be a list of security vulnerabilities found as either noise, suspect or definitive.  It will then be up to the security engineers knowing the system architecture and network topology working with the application developer to determine whether the vulnerability results in a valid threat and what risk level based on the impact of a possible security breach. Once the risk for each application is determined, it can be managed through an enterprise risk management system where vulnerabilities are tracked, fixed and the risk brought down to a more tolerable level.

7 – Consider implementing a Centralized Mobile Device Management System

Depending on the Mobile Security Policy that is in place, you may want to consider implementing a Centralized Mobile Device Management System especially when Bring Your Own Device (BYOD) mobiles are in the mix that can:

  • For mobile devices, manage certificates, security setting, profiles, etc through a directory service or administration portal.
  • Policy based management system to enforce security settings, restrictions for organization-issued, BYOD mobile devices.
  • Manage credentials for each mobile device through a Directory Service.
  • Self service automation for BYOD and Reducing overall administrative costs.
  • Control which applications are installed on organization-issued applications and check for suspect applications on BYOD mobile devices.
  • A system that can remotely wipe or lock a stolen or loss phone.
  • A system that can detect Jail-broken or rooted mobile devices.

8 – Security Information and Event Management (SIEM)

Monitor mobile device traffic to back-end business applications. Track mobile devices and critical business applications and correlate with events and log information looking for malicious activity based on threat intelligence. On some platforms it may be possible to integrate with a centralized risk management system to specifically be on alert for suspicious mobile events correlated with applications at higher risk.

References:

Your journey toward IAM maturity requires the right MAP

Three Characteristics of a Mature Identity and Access Management Program

Identity and Access Management (“IAM”) as an industry started gaining significant recognition and momentum around 2003. During these last 12 years, we’ve seen product vendors come and go, we’ve seen industry consolidation, and we’ve seen important product innovation driven by real business need.

While all this has been going on, many companies have leveraged IAM products to achieve important and significant gains in security, efficiency and compliance enforcement. On the other hand, some companies have tried and tried to establish effective IAM programs only to fail in their attempts to affect real change.

What makes one company succeed and another one fail while attempting to leverage the same products and technologies? What are the characteristics of a truly mature IAM program?

Over the next few weeks, I will attempt to address these questions. I also hope to create an important dialogue among those of you who have “been at it” for the last 5-10 years and have seen and been part of great successes and colossal failures. Although I have been part of hundreds of IAM projects, and will lend my experience to the discussion, you, as the readers and contributors, may have much more to contribute to make this topic come alive. Will you help?

Let’s get started with three important characteristics of a mature IAM program. This list is not exhaustive but these capabilities are common among organizations that have made IAM a strategic part of the IT infrastructure.

#1 – User Identity Integration

Pieces and parts of a user’s identity can exist across many different systems in an enterprise. HR systems are an obvious source along with IT systems like Active Directory. Then there is the badge or physical access system, the phone system, and various business applications that become critical for a user to perform their role. Before long, keeping up with all these disparate systems and keeping user attributes current becomes unmanageable. Most organizations recognize the problem and also recognize the need for a consolidated view of a user’s identity. It seems simple enough, but it takes planning, time and good processes to move an organization down the road to centralizing processes, automating synchronization, and removing redundant identity attributes from across the enterprise.

#2 – Account Provisioning

Creating an account on an appropriate system with the correct permissions is a straightforward task when you’ve been given the right information and you have the time to get it done. When a company grows to around 3,000 employees, the enterprise reaches a tipping point where going about this using people and manual effort becomes untenable. Too many requests for new accounts, or too many changes to existing accounts, or repeated requests to remove accounts for terminated employees all begin to pile up. This creates a backlog delaying new workers from getting started, hampering productivity, or creating security exposures where accounts of terminated employees remain active far too long.   Centralizing and/or standardizing the process can help but adding technology that provides automation will speed up the process along with enforcing identity standards, access entitlements, and important policies and standards. Automatic account removal of terminated employees is also a significant gain. All accounts on key systems can also be tied back to a central, validated user account eliminating unknown, orphaned user ids from across the enterprise.

#3 – Password Management

Password management activities face a similar challenge as an organization grows and adds more and more people, systems and applications. Initial steps should be to provide tools to help desk personnel centralize and automate this activity. Ultimately an organization needs to move this function away from the help desk and enable the end user to manage his own passwords on key systems, including resetting their own Active Directory password. This is another step that seems simple on the surface but can actually take a significant amount of planning and coordination to get it right and keep it running smoothly. Organizations that make a misstep on their first attempt find it difficult to gain user adoption the second (or third) time around. Eventually, standardized help desk procedures can assist the user community in adopting the self-service approach to managing passwords.

 

Identity integration, provisioning and password management are three essential building blocks, but there are another 8 – 10 key capabilities we could discuss that should be considered when talking about IAM maturity. What other capabilities would you consider to be essential building blocks? Please contribute to the discussion.

Up next, let’s talk about the essentials for planning a long-term, mature IAM program. If you’re just getting started or have been struggling to make progress, what are some of the keys to putting plans in place that can be effectively executed?

Mapping Manager DN in a Provisioning Policy

Below is a helpful little script that makes it possible for a provisioning policy (in this case AD) to map the correct DN for a manager:

/*AD Manager*/ 
var adDN = ''; 
var myServiceDN = service.dn; 
var mySupvDN = subject.getProperty('manager'); 
if (mySupvDN != null && mySupvDN.length >0){
    mySupvDN = mySupvDN[0];
    var globalid = mySupvDN.substring(mySupvDN.indexOf("=")+1,mySupvDN.indexOf(","));
    var myPersonSearch = new PersonSearch(); 
    var searchResult1 = myPersonSearch.searchByFilter("Person","(erglobalid="+globalid+")", 2);
    if (searchResult1 != null && searchResult1.length > 0) {
     var mySupv = new Person(mySupvDN);
     var supvUID = mySupv.getProperty('uid');
     if ((supvUID != null) && (supvUID.length > 0)){
         supvUID = supvUID[0];
         var myAccountSearch = new AccountSearch();
         var mySupvAccountList = myAccountSearch.searchByUid(supvUID, myServiceDN);
         if (mySupvAccountList!=null && mySupvAccountList.length > 0) {
             mySupvAccount = mySupvAccountList[0];
             var adDN = mySupvAccount.getProperty("eraddistinguishedname");
             if (adDN !=null && adDN.length >0) {
                adDN = adDN[0];
                return adDN;
             }
         }
     }
    }
}

Here is a list of steps that are being taken by this script to return the AD DN of the manager: Read more

Realizing Rapid Value from Identity Management Provisioning

We’ve been working with most of the leading Identity Management/Provisioning tools since 2003. Most of the products have been acquired or rolled up into a larger suite of products. This process brought maturity, stability, and added investment to the industry. This helped the products and industry establish a place in the IT infrastructure that’s here to stay.

When we first meet with a prospective client we always ask the question, “What’s driving your need for provisioning?” Most organizations will talk first about audit compliance forcing these initiatives. And although this driver has finally elevated the effort to become a budget priority, the fact is that most companies wanted to do the project years ago simply to improve the overall security of the organization. And that can still be done pretty quickly.

So what if you’re one of those organizations that still can’t seem justify the project? Let me suggest you consider a streamlined, rapid approach that will enable you to realize value quickly — I mean in a matter of weeks vs. months or years! Read more

We have the coolest security technology partners!

Recent press supports our direction on selecting leading edge security technology partners. Not long ago, NetWitness found the most invasive Netbot in recent history.

Now our cloud-based monitoring solution partner, Alert Logic, discovered a serious bug with Facebook.

IDG reported “Facebook is fixing a Web programming bug that could have allowed hackers to alter profile pages or make restricted information public.

The flaw was discovered last week and reported to Facebook by M.J. Keith, a senior security analyst with security firm Alert Logic. Read more