|
|
|
|
|
|
IT Policy & Security Compliance (Part Two)
|
SIEM deployments cut across organizations’ boundaries. In IT you can expect to involve stakeholders in architecture, operations, help-desk, and security functions. Within business management, you may need support from finance, HR, compliance, risk management, and the sponsoring C-level executive. It’s essential that any SIEM project secure buy-in from all stakeholders before work begins in earnest. Once the team is assembled, you are then ready for the 4-step process to perfect SIEM preparation.
Step 1: ASSESS
This step is all about gathering as much relevant information on key stakeholder requirements and thoroughly auditing your existing IT and security arrangements.
The ultimate aim is to establish an acceptable known base line for security, from which you can build the rest of the project. So you should perform vulnerability assessments on existing systems and networks, identify current or potential weaknesses and fix them first. Then you can start to understand priorities, such as which critical systems to plug into the SIEM first, what levels of detail are needed, and which parts of the infrastructure are taking most heat.
Step 2: SIMPLIFY
Attempting to integrate SIEM with complex or contrived infrastructure will add time-consuming work and extra cost at each stage of the project. So look for any opportunities to simplify your networks. Topologies may have changed significantly since your original deployment of firewalls, IDS, and other security products. Users may have relocated physically or migrated to new methods of accessing their applications and data. It may be possible to retire some of your security systems and consolidate networks and security policies associated because their functionality has now been added to other products.
To help with this, review the placement of security infrastructure in the light of the threats and vulnerabilities you catalogued in Step 1. Remove, redeploy, or reconfigure security products that serve little or no purpose in their current position. Take the opportunity to retire legacy access methods, and reduce the number of routes into your network. Again based on your work in stage 1, consider grouping high-value assets together in a high-security “green zone”.
One of the most powerful tools for adding simplicity to Default Deny – allowing users and applications to perform only specified tasks across networks and servers, and denying anything else. This means more elegant configuration, fewer events, and greater overall security. Server consolidation brings further management and cost benefits. Remember: keeping it simple maximizes SIEM benefits.
Step 3: TUNE
In SIEM terms, tuning applies mainly to just one system: Network Intrusion Detection/Prevention, which generates more alerts than any other product. In essence, it means weeding out false positives. The strongest reason for tuning an IDS is that if they have to report every event, the IDS may not keep up with the traffic and information will be lost.
The cost of your SIEM system is broadly proportional to the number of events per second it must handle and potentially store. And as we’ve gone a long way in Steps 1 and 2 toward streamlining infrastructure, tuning the IDS sensors in order to reduce the most obvious noise going into the SIEM can dramatically reduce the flow of spurious alerts.
One of the easiest IDS tuning activities takes advantage of the fact that you can logically group servers by OS, and so can tell the sensors to selectively ignore Windows attacks directed at UNIX machines and vice versa. This logical grouping does not necessarily mean moving systems and cables. Using a combination of intelligent port mirroring and tuned IDS you can opt to show a given sensor “just the UNIX traffic” and so obviate the need for running Windows signatures and their false alerts on that sensor or interface.
Another option is to screen alerts on Web servers, by qualifying signatures such as Python, PHP, Perl, .net and so on, in or out of the alert signature list.
Step 4: DEPLOY
To ensure success, make sure that the SIEM project is aligned with your business strategy, and consider what value the SIEM is supposed to deliver.
Also remember to deploy the solution in stages, with definable goals concluding each stage. One of the common reasons for failure is that the project tries to achieve too much, too fast – so proceed with care.
SIEM should help you free up the small, specialist security team from doing day-to-day investigations and device support work. It should enable you to meet compliance requirements for reporting, without large amounts of custom coding and scripting. And critically, it should cut the chances of a breach passing unnoticed, and shorten the clean-up period, reducing overall exposure to risk.
Remember, the ultimate SIEM goal is to help your existing teams do more, be more reactive with their current resources and to enhance security. Now that’s well worth a little extra preparation.
Perfect SIEM Preparation: The Crib Sheet
• Establish a cross-department steering committee first, to ensure all parties are onside.
• Build a security baseline: assess activities & risks, prioritize them, and how you’ll remediate.
• Simplify the network before installing large management systems to shorten implementation time, reduce event numbers and raise input quality for SIEM
• Boost signal to noise ratios for reduced hardware load and fewer events.
• Phase the roll-out.
• People and procedures are vital for successful deployment.
References
The British Computer Society
Symantec Enterprise
BIOS
"The ultimate SIEM goal is to help your existing teams do more."
Posted by ROOT Technologies
|
|
|
