KSE Technical Controls (Insider Threat Round-table Continued)
A previous post, “New methods needed for addressing insider threats“, was based on a panel discussion that pointed out hard challenges in preventing the insider threat. NISPOM CC2 and Executive Order 13587 for Federal government departments and agencies are now mandating insider threat programs to be implemented. The requirements here represent a very low bar, – entry level at best. If you think that the insider threat should be taken more seriously, you may want to learn about technical controls which provide specialized insider threat prevention tools.
This post will describe ways to handle the hard insider threat problems identified in part 1 with advanced technical controls, such as those featured in KSE – the kernel security enforcer by Trustifier.
Problem 1 – Little ability to prevent escalation of privilege.
Recall from part one,
“attacks require two steps: gaining access, which usually involves standard users, and then elevating rights.”
“…external attackers become an insider problem once in the network, ‘masquerading as privileged users‘.”
An enterprise that can’t prevent abuse by authorized insiders is going to have trouble defending against attackers posing as them. It is important to prevent unauthorized privilege elevation though. KSE converts any system it is installed on, into a verifiable trusted execution environment and denies attempts at unauthorized elevation of privilege. This in turn prevents unauthorized changes to user operational privileges.
Why is this important?
Removing ability to elevate privileges reduces opportunities for persistence.
Any one who doesn’t consider this benefit of trustworthy computing misses an important lesson in defender advantage. The regular user already is working under cover of authorization. One does want to make it as hard as possible for external attackers posing as them to operate freely in the network, and limit their ability to be persistent.
Problem 2 – Difficulties preventing abuses by privileged users.
Preventing the insider threat should involve setting limits for all categories of user privilege. Do privileged users really need “carte blanche” privileges? Sure, there are always some privileged users who feel entitled and and that rules are for others. Does growing insider threat awareness suggest there should be some kind of “rules of engagement” and boundaries set for all users? Just like with a teenager, sometimes if you give an inch, they may take a mile, even innocently. There’s a good reason for setting boundaries;
Insider threat prevention should have as a goal, the reduction of opportunities for abuse of user privilege.
Isn’t this the goal of the basic security concepts of least privilege, separation of duties, and user provisioning?
KSE facilitates and delivers need-to-know security for everyone! Boundaries and limits can be set using fine-grained access controls, either role- or rule-based, to networks, systems, directories or individual files. Such boundaries will apply to either authorized users who have been granted privileges, or someone who has stolen their user credentials and is posing as them. KSE rules are based on business trust relationships and map to human activity based on goals, objectives and activities of the business in order to align security with the business. Those rules can and should, include privileged users.
Problem 3 -Difficulty dealing with the standard user.
Everything for the privileged user applies to regular users as well. You may recall that KSE is a reference monitor or “authorization engine”. This provides “security owners” security mechanisms and paradigms to define access and operational authorization on a per user basis within a system and across the network. The combination of KSE user-centric rule setting, automated labelled security (MLS), plus a positive security model design, faciliates whitelisting of user end-behaviors!
What can this deliver?
Attempts at unauthorized actions and behaviors for all users can be denied and flagged in real-time.
Using KSE it’s easy to separate whole groups, such as system administrators or admins from the data other user groups, such as human resources directories or customer data. Who really needs to see R&D directories? How about only those in the R&D user group? If staff in the organization don’t have access to data that is not required for their job duties, the opportunity for abuse is curtailed.
Problem 4 – Differentiation of authentication and authorization controls.
It’s amazing that so many people don’t get that authorization rules are supposed to follow user authentication. Instead, authentication is used as a proxy for non-existent authorization rules on COTS systems. One can take advantage of KSE, an authorization engine, to provide enforceable per user authorization rules. The KSE framework facilitates the integration of the various sets of per user access control privileges for work groups and business units, working in tandem with authentication or identity access management (IAM) solutions. This combination means KSE facilitates building out powerful need-to-know security across COTS platforms of the network. The layers of authorization rules set behavior boundaries post-initial-access as well.
Problem 5 – Expanding Risk Plane
According to the panel, the tools for determining and defining user access rights, and then enforcing them in ways that can scale across legacy, cloud, mobile etc., aren’t here yet. That’s inaccurate actually. KSE is scalable multilevel security and mandatory access controls that scales across domains and platforms. KSE user-centric rules access privilege rules can “follow” users from the enterprise, to mobile and cloud space. Rules can be set locally or pushed out from central management consoles. KSE rule-sets plug right in to the APIs of your provisioning systems.
Problem 6 – Requirement for in-line enforcement rather than post analysis:
To reduce opportunities for privilege abuse most effectively, granted access privileges should be enforceable. When enforceable need-to-know security for every user is possible, protecting against the insider threat becomes much easier. KSE features kernel level rule enforcement. The ability to deny unauthorized access attempts, or actions heads off problems “at the pass”. Remember, one wants to remove opportunity to abuse user privilege.
KSE maps its rule enforcement to the human activity and aligns with the goals and objectives and activities of the business for great fitting rule creation and enforcement. Plus, it uses a positive security model. This allows potential insider issues to be dealt with immediately as security officers can be flagged in real-time if required. While monitoring and analytics is still used, this is a more proactive approach to security than incident backtracking using only monitoring and user risk behavior analytics.
More from the KSE Insider Threat Toolbox
KSE features additional technical controls that will aid in dealing with each of the insider threat challenges discussed above.
KSE immutable and tamper-resistant, time-stamped, user-centric auditing
This a big deterrent to malicious miss-behavior when privileged users or rogue system administrators realize that there is no way to cover tracks. KSE audit traces are mathematically and provably forensically defensible.
KSE protects clear text data in use
Authorized users access data in clear text, when they perform their duties. Encryption may not be a useful data protection tool for the insider threat. KSE is able to separate any user from sensitive data set as required, without using encyption. It does so by enforcing per user caveat access privileges, via digital separation at the OS kernel level.
KSE also has its own risk analysis engines to detect aggregate data collection and insider collusion to identify and deny probable insider incidents, in real-time. KSE risk analysis engines incorporate Driller and Decider analytics modules in an environment that is already well defined for allowable user behaviors. The AI engines can be used to set up user trust credit scores to predict and deny abuse of privileges, flag possible insider collusion and detect aggregate data collection.
To Reduce Insider Risk – Reduce Opportunity for Privilege Abuse
This post has discussed how technical controls featured in KSE can help one to deal with the toughest insider threat challenges. While new compliance regimens like NISPOM CC2 may help to bring about more awareness of insider threat risk, internal controls that limit opportunities for privilege abuse and enforce behavior limits are still needed. Even if your enterprise is able to satisfy initial compliance requirements, it will still require more protection to prevent it from being a victim of the insider threat.