Incident support should include security authorization requests, and incidents should be easily created for follow-up on a security event such as an access violation or logging. The security officer’s follow-up notes can then be made part of and associated with the security event.
It should be easy for a security officer or administrator to open an incident, add information about the request, authorizations, include emails, etc., and relate it to a specific authorization or administrative change for security incident follow-up, etc. For incidents that can be related to categories such as the Health Information Portability and Accountability Act (HIPAA), Sarbanes- Oxley Act (SOX), Gramm-Leach-Bliley (GLB), etc., there should be a way to categorize the incident so when the auditor requests all incidents relating to one of these categories, the request can be easily satisfied.
Security access definitions are a mess and need to be cleaned up: Security officers and administrators are afraid to try cleaning them up and make them follow company policy. They’re afraid the business will stop because they didn’t allow a critical job or transaction to execute, but current regulations require review and cleanup of these definitions. Security systems must provide the ability to test new security definitions in the production environment, so the security officer can feel comfortable revising security definitions without risking production interruptions.
Security systems must monitor new security definitions to ensure they follow company policy: Security systems must provide an autonomic capability to raise the quality of the security definitions; for example, by recognizing conflicting or undercut access permissions and new privileged user attributes and periodically bringing them to the attention of the security officer. Also, as the security officer cleans up the access permissions, or the security administrators add new access permissions, the autonomic portion of the security system must recognize changes that will introduce new exposures and either immediately raise them with the security officer or even automatically roll them back.
Security systems also must diagnose and assess security issues based on usage and periodically provide the security officer with suggestions on how to fix them. For example, it would be nice to know that a RACF group hasn’t been used for access in the last three months, or that a list of specific users who are connected to the group hasn’t used it for access in the last three months. Then the security officer can decide to clean up the access permissions or leave them alone awhile longer.
There are many security violations and logging messages: The number of security violations and loggings used to be small. But, as the number of datasets, transactions and users has skyrocketed, so has the number of violations. Today’s security officer can’t review them over his or her first cup of coffee each morning and often faces the equivalent of an eight-inch thick report each morning. One person (or even a few generalists) can’t adequately monitor the security events happening in today’s environments.
Security events must be able to be categorized based upon importance in addition to category or regulatory— such as PAYROLL, NUCLEAR, SOX, HIPAA, GLB, etc. Security systems must be able to produce and distribute security reports via email to interested parties based on their events of interest. The interested parties know what events pose an imminent danger.
Security officers and other interested parties must be notified immediately when a critical event occurs: Security systems must be able to alert interested parties via email or SMS message to their cell phones immediately when a critical event occurs. For example, this could include everything from a security violation in attempting to access the nuclear waste shipment schedule to two or more consecutive invalid password attempts by a user with special privileges. Authorized individuals must be able to subscribe to these kinds of events and indicate the mechanism for alerting them.
Security administrators need a user-friendly graphical interface that leads them along and helps them avoid mistakes: Initially, the security administrator position wasn’t required; the administration was handled by the security officer, who normally came from an applications development or operations position. Now, the security officer is assisted by several security administrators who handle the routine tasks of accepting requests for additional users or access, obtaining proper approvals and entering the required new access permissions. These new security administrators almost always come from clerical positions. Unfortunately, the native interface to current security systems is a terminal emulator, emulating a terminal that’s no longer being manufactured and using a programmer interface rather than a clerical interface.
The number of security administrators familiar with the mainframe 3270- style interface has significantly dwindled, but the pool of potential security administrators who understand a graphical, Web-based interface is massive. So, security systems must offer a graphical user interface that helps prevent mistakes by providing drop-down lists, type-ahead technology, hover help text, etc., to help security administrators do their job effectively and with few errors.