July 18, 2023

Security Configuration Exception Tracking

7/18/22 - There seems to always be someone that needs access to something that is just outside the boundaries of their job duties and/or security roles. When it comes to security, that thing is usually more than what policy would normally allow. These kinds of exceptional activities or elevated access—although potentially necessary to conduct business—are a risk. Therefore, it’s necessary to manage and track these exceptions so that elevated access is not allowed in perpetuity, and does not lead to risk of compromise in the future.

Examples of these types of exceptions are:

Removeable media storage devices
You may have a department manager or other job role that routinely needs access to customer NPI on USB drives in order to perform business processes. Risks here include an employee unwittingly installing a payload from the device or from the internet as called on by the device or its contents.

External email or forum access
IT administrators may need access to web-based email hosted by another company to test email flow from outside the institution, or to send email in the event of a disaster. Or they need access to forums to research and resolve issues. Risk here includes an inside threat actor exfiltrating NPI or other institutional information to the outside world via these sites through the upload of data or files.

Administrator access
Based on size and complexity and limited human resources for IT administration, certain operations staff may have administrative control of user access for certain assets. It is common for wire transfer systems which are often controlled by wire or finance operations staff. Permissions may be altered or elevated out of perceived efficiency needs, which could lead to a threat actor using those exceptions for fraud or theft, or and inside threat actor could elevate and retract permissions at will, attempting to obfuscate activities.

When these types of exceptions are needed, the institution should have documentation supporting the exception that shows who made the request, when the request was made, the details of the request, the inherent risks and calculated inherent risk score, any compensating controls, and finally the residual risk of the exception. The documentation should then show senior management approval, possibly including board approval, for these exceptions. Review of these exceptions should take place no less than annually, and some exceptions may require more frequent review and monitoring based on the calculated risk. Tracking and approval is needed even if the duration is just for a time of disabling a security control to accomplish the specific goal, and then enabling it again immediately after the results are achieved.

Finally, as previously mentioned, in most cases these exceptions should not be perpetual. If exceptions are to become accepted risks, then serious consideration should be made to formalizing them as a normal part of policy and/or standards. However, formalizing an exception into an accepted risk, and then into policy carries the added risk of running afoul of an exam or audit authority being at odds with the policy, just like they can be with accepted risks. Either way, documentation and approval of reasonable actions and activities associated with the exception and the management of risk is the key. Not doing so will more likely result in an unwanted outcome and insurance claim, which can be much worse than the wave of a regulatory finger.

If you would like a sample policy for Security Configuration Exception Tracking or would like more information, please reach out to anyone at 10-D Security. Additionally, our 10-D Academy covers this topic and many more. We are here to help.

PDF Icon Download Blog