This column is available in a weekly newsletter called IT Best Practices. Click here to subscribe.
As you go about your daily business online, think about the limitations you encounter that are designed to reduce risk. Various controls verify who you are, require your express permission to go ahead with a questionable transaction, or deny an action if there's too much risk.
For example, if you try to jack up the sound too much on Windows 8 it warns you that making the sound too loud can be dangerous to your hearing, and asks you to confirm if you really want to do this. If you go to a bank ATM and want to withdraw $1,000 from your account, the bank may limit you to a withdrawal of only $300 per day to limit the risk of abuse of a lost or stolen card. If you want to change a password for an online account, you might be challenged to enter secret information to prove your identity, or a CAPTCHA to verify you are a human and not a machine. Even cars today have programmable keys that limit the maximum speed or the maximum sound volume so parents can have some control over how their kids behave when driving the car.
What if you could take that concept of building safeguards – policies, really – into any cloud-based or web-based application for risk mitigation? Rather than simply denying an action that could have some risk to it, you set parameters around what someone is allowed to do, and those parameters can be specific to the context of the action.
For instance, suppose a user has valid login credentials to access your company's instance of Salesforce, but this user is on a personal device and logging in via a non-corporate WiFi network. He wants to download a lot of customer contact records. This seems to be unusual behavior. Do you allow or deny this action? Allowing the activity could enable an unauthorized person to steal sensitive information. Denying it could inhibit the productivity of a genuine employee. Wouldn't it be better to challenge the user with an additional form of authentication – perhaps require an employee ID number – before you decide what to allow the transaction?
Here's another example of injecting a policy into an application to mitigate risk. An person with administrative privileges logs into Go Daddy and wants to change a DNS setting for your company domain. Because DNS hijacking is quite common, this action is considered risky and should require validation before it's permitted. What if the application could generate a ticket in ServiceNow that sends an alert to the IT director in real-time, and that person must approve the change before it can be committed?
Most web-based and cloud-based applications don't have these types of real-time safeguards built in—but they should. You could do a lot of risk mitigation if you had a way to set customized, contextual policies for every application your organization uses, regardless of where the application resides (i.e., in the cloud or on premise) and whether it's a homegrown or commercial application.
Security controls for web and cloud applications are mostly focused on credential-based binary decisions. If a person has the right credentials, he can login to the application; if he doesn't, he is kept out. And even if he has the right credentials for login, his activities post-login can be nefarious but there's no check for that.
FireLayers brings to the table a very granular level of contextual control for any web- or cloud-based application. The vendor calls this approach "adaptive mitigation." It's the notion that you want to make a decision about an action in an application based on the user's credentials, the context in which he is working, the content he is trying to access, and the behavior he is exhibiting. After considering all these factors, you can mitigate the risk of the action by fully blocking it, fully allowing it, requiring strong authentication before allowing it, issuing a warning or alert before allowing it, or forcing the use of additional security tools such as DLP or anti-malware.
FireLayers brings a full stack of security to cloud and web applications, as shown in the graphic. The baseline of security (shown in tan in the graphic) is application agnostic. FireLayers has the ability to analyze the conditions of the network, device, operating system and client to provide clarity of context of an attempt to login to and continue using any application. For example, FireLayers can analyze the IP address of the session, to see if it has a bad reputation, or if it suddenly changes during a session, which might indicate the session has been hijacked. Under the latter condition, the session could be dropped entirely, or the user could be prompted to re-enter his credentials.
The next layer on the security stack that FireLayers addresses is the user identity (shown in yellow in graphic). A user might first go through LDAP authentication, and then FireLayers adds more context based on parameters such as location, device, operating system, browser, and so on. This level of security relies on so much more than simply possessing the right credentials.
And the third layer of the security stack is the application itself, and the content accessed via that application. FireLayers has predefined rule sets for numerous popular applications but the vendor can work with any web or cloud application you want to use. An example of applying security at this level might be this. Suppose an employee is logged into Salesforce and he wants to upload a file to a customer's record. FireLayers can capture that file and run it through a DLP tool to make sure it doesn't contain corporate confidential information. The mitigation occurs in real-time and without breaking the Salesforce session.
FireLayers can inject any type of real-time functionality for risk mitigation that you want. It does this through a platform that connects to your chosen applications, either through an API or by configuring the SAML proxy. Then policies are defined using rule sets, which are made out of rules using the XACML standard. In this way you can define the subject, the environment, the action, the condition, the decision and the obligation. In other words, you can granularly define the who, what, when, where and how of application access and activity. Policies can be for individual applications or across applications.
FireLayers claims to be the first gateway provider that is able to get to such a detailed level of application control and risk mitigation for any type of application on the web or in the cloud.