Your Cafeteria Menu Web Application Might Be Sensitive!
This article is focused on the exercise of determining the security profile of an application to determine what level of security controls/rigor is required for the application – after all, implementing a security control more expensive than value of the data never justifies the ROI.
So yes, usually the biggest goal of determining the security profile of the application is to implement security across the enterprise in a cost effective manner that appeals to senior management to obtain their buy-in.
I have looked at number of Security Risk Management Programs, read books, talked to security professionals about the methodology used to determine the security profile of their application.
The usual answer involves the process of determining whether a given application processes PII or company confidential data AND if the application has internet presence or not a.k.a. a checklist approach.
This is great, but along with data sensitivity and exposure of the application one needs to consider the availability requirements of the application at par with the data sensitivity and exposure of the application, not any less.
Besides this, when one considers data sensitivity, only the profile of the data is analyzed for classification – but what I am wondering here is what about the sensitivity for the type of credentials used for an application.
Let’s discuss an example of each of the above cases, starting with why availability factor is equally important as data classification and exposure of the application.
Lets say there is an application “X”, that does not process any sensitive data – neither PII nor company confidential, neither the application is exposed to the internet, however the business function of application “X” is to obtain a non-PII data, which is consumed by multiple business critical/sensitive applications that would not be able to complete their transactions without this information.
So when we attempt to determine the security profile of this application – neither is it exposed to the internet nor does it process any sensitive data, but its availability factor is critical for a number of core enterprise business applications.
Unfortunately, if one does not review the context/environment this application operates under – we would determine it to be of a very low security profile, and hence require only very low security rigor.
This could be a big mistake, since an employee with malicious intent would have a free ride to take down this application considering the application’s low security rigor requirements, subsequently affecting availability of critical business applications resulting in a financial impact or negatively impacting the enterprise brand.
It is important to realize the availability factor is the usually the number one priority for any enterprise of course along with any regulations that are applicable – since it directly translates to money, brand image, etc.
Next, let’s discuss an example of why credential type used to authenticate to an application is an important attribute that should factor in the process of determining the security profile for an application.
Let’s take an example of an intranet cafeteria menu application that has no sensitive data and is not exposed to the internet and not critical for an enterprise to have high availability.
However lets assume that in order to log into the web application, one requires their LAN credentials. If data classification is determined through profiling the application data, the application will assume a low security profile with no sensitive data – hence requiring low security rigor.
Now, if this application is compromised/or the credentials sniffed the attacker has pretty much keys to the kingdom – he can invariably assume the privileges of any employee who uses this web application. The stolen account credentials can then be used to execute attacks in other critical enterprise applications again resulting in PII leak, financial impact and negative brand image.
Determining the security profile of an application is a very involved and complicated process – one needs to understand the business logic of the application, its integration with other applications and the security profile of the context this application interacts with.
As a part of this exercise there may be outcomes that can make it extremely complicated to justify ROI in implementing security controls. In these situations one needs to re-think the objective – and ask questions like what is the ultimate objective of profiling applications from security standpoint, and if it doesn’t make sense in one of the use cases an alternate method could be for example – not use enterprise credentials for low profile application.
I am not proposing this, but this could be justified solution for certain use cases. Or another way to look at it would be to create network security zones that club tightly integrate application both from business and technical standpoint in one zone, where each zone is applied security controls based on the security profile of the zone a.k.a. the information system it houses.
In the end, I will serve a reminder to not forget to put availability as an equally important attribute compared to data classification and exposure of the application – remember “Production is no.1 priority for any business!!”
