A recent IBM X-Force Threat Report focuses solely on the insider threat and its various incarnations. It’s a comprehensive and compelling read. It certainly got me thinking, and I began asking myself some questions about the nature of insider threats and how to best protect against them.

Protecting Against the Insider Threat

Is an insider threat something we really need to worry about? According to the X-Force data, people with inside access to critical information or private networks are the source of more than half of all reported cyber events. The report noted that while outside actors were responsible for 45 percent of the attacks recorded in 2014, 55 percent of attacks were executed by users who had insider access to organizations’ systems. Insider threats may be of particular concern to organizations using cloud platforms, and there are certain considerations that will expressly apply to enterprises in these situations.

Start by considering what’s unique within the software-as-a-service (SaaS) hosting environment. With cloud adoption, development and support staff are closer to production systems than they have ever been in the past. The agile and SaaS models expect rapid application deployments and bug fixes. This can sometimes conflict with our needs of maintaining compliance and adhering to control polices within the environment.

What role do security professionals play in this threat scenario? Controls from enterprise positions such as the chief information officer (CIO) and chief security officer (CSO) go some way to instill deterrence to insider threats. But we should see our role as gatekeepers to the cloud platform, providing the first line of defense with prevention and detection.

Then it all comes down to the big question: Are we doing all we can to mitigate the risks? From the report, we see an enterprise-wide approach is required. In a previous article we touched on some of the issues stemming from the relationship between DevOps and SaaS, but in this scenario, there are three areas relevant to our role: authorization policies, separation of duties (SoD) and privileged user management. Let’s measure ourselves against these.

Authorization Policies

As part of any authorization process, we’ll first start with identifying the services and systems we wish to authorize access to. A differentiator with cloud hosting environments is the need to protect management interfaces. Infrastructure-as-a-service (IaaS) providers typically support Web and API interfaces. Access to these services can be as destructive as accessing the platform itself, with data deletion, service outages, etc.

When evaluating authorization processes and tools, cloud platforms require:

• Line-of-business approval. Given the distributed nature of development, operations and support teams, we must rely on local line management of requesters to form part of the approval chain.
• Continuous business need. Rotation in development and DevOps roles means we must ensure persons holding authorization privileges have their need for access periodically reviewed.
• Employment verification. Ideally, employment status is tied directly to authorization systems. When an employment is terminated, all system accesses should be removed immediately.
• Extensible APIs. When we consider the third-party vendors providing services within our cloud offering, we need to ask ourselves what interfaces exist, what risks are exposed and how we integrate them within our authorization platform.

Separation of Duties

While not directly referenced within the report, a clear policy for SoD is critical to protecting our environment. IT organizations have always been aware of this need, but it’s more important than ever within cloud and SaaS due to the expanded set of stakeholders. For example, if our cloud platform contains customer data repositories, we are faced with scenarios such as:

• Installation and upgrade. Persons may require access to systems and applications but not data access, be it either encrypted or unencrypted information.
• Data backup. Persons or tools performing this role need read-only access to the data; however, they don’t require unencrypted access to complete their role.

We must look to combine encryption technologies with authorization tools here.

Privileged User Management

Although implementing rigid authorization processes for day-to-day activities provides good protection, there will be times where ad hoc privileged access is required, such as application SMEs not part of the managed support organizations.

The business and application owners will be demanding quick access, but it is our responsibility to balance this with a level of control over the platform. When looking for solutions for managing privileged users, we will look for:

• Authorization. We must insist on maintaining an authorization workflow for access requests. To facilitate the urgency of these types of requests, look at streamlined request channels with a quicker response time.
• Accountability. Sometimes we will rely on using shared privileged user accounts, but here we must still ensure end user accountability. Introduce the concept of key rental, where access credentials are assigned to only one individual for a set period.
• Auditability. Ideally we will look to support real-time activity monitoring for these user activities. Things like keystrokes and desktop interactions should be recorded and archived. These must be reviewed on a daily basis.
• Revocation. Any privileged access granted must be temporal. One-time passwords or authentication tokens with an expiration time are useful here.

Cloud platforms introduce additional complexities when looking at the insider threat. To address these, we need to work with our cloud development and support organizations in understanding their requirements and providing a comprehensive solution, which must include robust controls that take into account the use of IaaS provided by a third party.