For years, security analysts have provided information on products and services that can ease some of security managers' worst pains. From Simple Mail Transfer Protocol (SMTP) authentication to virus scanning to intrusion detection, security managers have received knowledge on tools that turned out to be useful for the reasons they were promised. For a long time, simply having tools to do the job was sufficient. Security managers were so caught up with the latest threat that they could not take time to stop and think about whether these tools were doing the best job, what this means to the business and what they would do with them in the long term.
Gartner's now infamous declaration of intrusion detection systems (IDSs) as "market failures" scared security managers. To Gartner's credit, the statement had been taken out of context, but it still seems like Gartner was betrayed by the very group of analysts that had told it IDS was great—even necessary—only a year or two before. Much to its chagrin, Gartner should have seen this coming. The company had been repeating to itself and management that "security is a process, not a product." Clichés like "security is an onion" have become as commonplace as the word "synergy" in marketing circles. Security, from the very beginning, has always been more than just solutions that address singular pains; it has been about the unification of the ultimate security triumvirate: people, process and products. Security managers knew this. That is what makes them "security people" in the first place.
If more than IDS is truly dead, how can security products really make sense for a business? Security managers might be able to manage 10 disparate security tools with 10 disparate central points of management, but is it really the best way? For institutions with plenty of full-time security staff, it might be good enough. The reality of the budget situation for everyone else is that it is not. Faced with mounting pressure of regulations such as the US Health Insurance Portability and Accountability Act (HIPAA), which applies to healthcare institutions, and the US Gramm-Leach-Bliley Act (GLBA), which applies to financial institutions, internal auditing and business continuity need a place to come to that says "this is what all of my tools are doing, this is the overall security situation we face, and this is what I am doing about it." This is what security information management (SIM) products try to bring to the table (see Figure 1).
SIM products from vendors including TriGeo, ArcSight, NetForensics and NetIQ (among others) have a few core pieces that make them tick: centralized monitoring, reporting and policies. These products take information from the majority of the infrastructure (tools such as firewalls, routers, IDS sensors and AV scanners), put it all in a central location and let security managers decide what happens when certain events occur.
Policies can be as simple as, "If you see a virus, send me an e-mail" (which seems simple, since most antivirus products can do this internally), to something more complex, such as, "If you see what looks like a worm infection due to a sudden increase in logon failures and SMTP traffic from the same PC and it is on my remote network, notify the on-call IT staff." Later on, to satisfy audit requirements, the consolidated database can be consulted. Some SIM products provide real-time monitoring of events as they come over the wire, while other vendors take a purely database-centered forensics approach. Still others fall somewhere in the middle, with a not quite real-time command center (see figure 2).
This sounds promising, but how does one know if SIM is right for the organization? It seems like a generally decent thing—something that consolidates and makes better use of existing tools rather than just being another tool to monitor. If one already has automated logfile management, SIM is the next logical step, but it might be harder to justify the up-front value. If logs are not being monitored, SIM can directly address that issue, and the additional value of reporting statistics and policies can put it over the line.
Each SIM vendor has something that sets it apart, whether that is scalability, real-time remediation (active response), statistical feedback loops or extensive forensics tools. Depending on the needs and size of an organization, these different tools may provide critical pieces to the puzzle. Some products are targeted at large organizations with a lot of staff, while others are more "no-nonsense" and have set out to address the immediate needs of small businesses whose IT staff is stretched thin. Each vendor has a different value proposition, but most hold true to the same central tenets of SIM described in figure 3.
When shopping for SIM vendors:
- Learn about the organization, not just the product and its price tag (though SIM products do have a large price variance).
- Read the customer testimonials to understand what kind of problems customers were able to solve.
- Make sure the critical assets, such as servers and firewalls, can be covered, but leave room for some flexibility.
- See a product demonstration, preferably a live system where the flow of data can be seen.
- Ask questions of the sales team that they may not be able to answer. The purchaser has to live with this product, and he/she needs to be confident that the vendor as a whole is doing what is in his/her best interest and the product is going to address the organization's needs.
- Get a feel for how the product is deployed and what the responsibilities are going to be during deployment. It is pretty safe to assume that the SIM vendors have deployed more SIM solutions than the buyer, so they should be able to answer any questions about how they will deploy in the organization's environment.
When implementing a SIM solution, buy-in is desired from all members of the team who are going to be required to use or implement it. How involved these people need to be is ultimately up to the security manager, but if he/she is going to start firing off e-mails to on-call staff about possible intrusions, he/she is probably going to want to make sure they have some input first. Everyone would rather be involved in the process than have something tossed their way, but the reality of the situation is that this can be time-consuming. Identifying the level of involvement of team members during implementation and post-implementation is going to put in perspective the level of buy-in desired. Anything from an informal "do you think this would help you?" to a full sales pitch with ROI calculations might be necessary, but it will make every team member's job easier in the long run.
SIM in the Long Term
It is safe to say SIM will stick with the core solution of centralization, but it is still developing. Most SIM vendors are relatively small companies that are just beginning to understand the long-term needs of their customers. Each of these companies has a small army of seasoned security professionals, but security is a constantly evolving problem, and SIM attempts to solve a much bigger chunk of that problem than "put my logs in a database, thanks." This relative uncertainty can be a good thing. These companies are more flexible, more customer-oriented and more willing to listen to their customers' concerns about security management problems.
In the end, nobody can make the decision about whether SIM is right for an organization other than the security manager and his/her team, but they definitely should listen with an open mind to what the vendors have to say. It is an evolving field that can solve some of the organization's biggest pains immediately with the promise of so much more in the years to come.
Nicole Pauls, CISSP-ISSAP, ISSMP
is a senior network security engineer at TriGeo Network Security. She has orchestrated nearly 100 SIM system deployments and is familiar with the challenges facing IT professionals. Her role as a system administrator and lead position on TriGeo's NATO5 Threat MatrixTM team has equipped her with network security knowledge and practical experience.
Information Systems Control Journal, formerly the IS Audit & Control Journal, is published by ISACA®, Inc.. Membership in the association, a voluntary organization of persons interested in information systems (IS) auditing, control and security, entitles one to receive an annual subscription to the Information Systems Control Journal.
Opinions expressed in the Information Systems Control Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA® and/or the IT Governance Institute® and their committees, and from opinions endorsed by authors' employers, or the editors of this Journal. Information Systems Control Journal does not attest to the originality of authors' content.
© Copyright 2005 by ISACA® Inc., formerly the EDP Auditors Association. All rights res erved. ISCATM Information Systems Control AssociationTM
Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, Mass. 01970, to photocopy articles owned by ISACA® Inc., for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.
INFORMATION SYSTEMS CONTROL JOURNAL, VOLUME 5, 2005