Remember these clauses & covenants while any enterprise application is being finalised for purchase
How to ensure that, as a CISO, all the tools are properly integrated with your SOC?
These clauses and covenants must be part of your Service Level Agreements (SLA) with service providers.
There are few parties while any enterprise application is bought for use within a company. They are: -
- User Department - End-users for the application. May or may not contribute to budget (to buy the application).
- IT - Budget to buy the application usually comes from this department. IT also helps in providing overall technical support in evaluating, procuring, deployment, maintenance, and support (on behalf of the customer).
- InfoSec - In regulated entities, this function is responsible to say 'go ahead and deploy it in production environment. It is safe to use, relevant controls are implemented to address any adversary exploiting any security weaknesses in this application and hurting us'.
- OEM (Original Equipment Manufacturer) - A term used to describe both hardware and software providers. People who create them.
- System Integrators (SI) - The company who helps in buying, implementing, maintaining, and supporting the application.
A basic premise - right of a customer to have a bug-free and secure application/ service delivery.
A covenant in legal term refers to a promise made by one party to another to either do or refrain from doing a certain act.
As a customer, it is our right to be able to use a secure and bug-free experience. Vendors must strive for it. As a consequence, they must not charge their customers for fixing bugs or security vulnerabilities.
What if this clause or covenant is not present in your agreements with the vendor or SI (System Integrator) of the enterprise software? They may seek compensation for fixing bugs or security vulnerabilities! This will cost your company by increased OPEX (Operating Expenditure). CFO won't be pleased.
Ask your application vendor/ System integrator to help integrating logs from the system to your SOC/ SIEM. You will have lot of difficulty in doing so, without their help.
Ideally, all security related logs from your IT tools should come to your SOC.
This is important so that SOC team is alerted when any anomaly happens.
HelpDesk/ Ticketing systems, business critical applications (Core Banking Systems, CRM, Enterprise Content Management Systems, version control systems, etc. are some examples of such tools.
There is a catch, however.
Someone needs to figure out those security logs (their construct, the most important security events from these tools and the type of logs that indicate those events) and prepare use-cases and alerts for them. your SOC will be a tooth-less tiger, otherwise.
Your SOC team will know how the SOC and associated tools work, they know how to collect the log, how to create use-cases and alerts. They will also know about logging capabilities of most of IT tools, e.g., firewall, IDS/ IPS, etc.
However, they won't always know which security events are logged by third party applications. They will need support from your SI (System Integrator)/ OEM (Original Equipment Manufacturer).
Your SI, while implementing the application for you, must help your SOC team to prepare appropriate use-cases. They may do so by making your SOC team aware of the what security events are being logged by the application, construct of the log, etc.
However, your SI/ OEM won't help you unless you make this activity, a part in their SoW/ SLA.
Make sure that you,
Put this activity in your SoW (while identifying proper SI for implementing your enterprise application), that you will need them to help your SOC team to create relevant use-cases and alerts. and,
add relevant clauses in your system integrator's contract.
Otherwise you won't get proper logs, nor will you be able to prepare appropriate use-cases/ configure alerts.
You will be sitting ducks when an attack happens on the application.
You also need to ensure that your SOC analysts fight alert-fatigue.
