In recent years, international, federal, state and local legislative and regulatory bodies have introduced a plethora of compliance laws and standards that have given rise to an information technology compliance "industry". This must seem to the onlooker like a maze of buzzwords (HIPAA, SOX, CFR, GLB), each of which would seem to address their own version of compliance to their own intended audience. At first, the labyrinth of different compliance regulations and standards would seem highly confusing. However, further analysis reveals that many have a common set of purposes, requirements and solutions. The fact is that compliance rules, be they created within an internal organization or by an external agency, have the same ultimate agenda; to improve the way that business is done, and to protect the organization, its customers and any other involved parties. As such, they cannot be separated from good business practices. Information technology compliance, therefore, is the act of meeting rules regarding the operation and management of information technology resources (no matter who made the rules, what kind of rules they are, or what the rules apply to), while at the same time doing so in a way that is supportive of the business ideology of an organization. To this end, compliance may also be seen as the act of achieving a desired end state. Any organization which wishes to achieve and demonstrate compliance should make use of a multi-phase plan or strategy which will include:
One of the biggest problems for most organizations is that they are not sure which regulations will affect their operations and technologies; or how and why they will do so. To make matters worse, the regulatory requirements are often given to technical professionals, who without training or guidance, are expected to interpret and implement them into the technical infrastructure. The end result of this is generally frustration and confusion; however, it doesn't have to be this way. Comprehending, translating and implementing compliance regulations is not an easy task, and is a workload that should be shared amongst both management and technical professionals.1 On the one hand, it is the responsibility of an organization's management to assimilate the various internal and external rules to create high level business policies to act as standards. On the other hand, it is the responsibility of the technical professionals to ensure that the system and network technology devices are configured in a manner so as to be compliant with the standards set in the business policies. However, what is often missing in this picture is the middle ground between the two, where the generic business policies get translated into a more granular technically specific language that can eventually be translated into device specific rules and configurations. Communication, patience and teamwork are of paramount importance for this step to succeed. Step 2: Performing a security risk assessment Once all concerned personnel within an organization understand the relevance and meaning of achieving compliance, they then need to understand the required work effort that it will take to make compliance a reality. In essence, they need to understand the current state of their information technology security posture, and the remaining deficiencies which separate them from the required state of compliance. Organizations should adopt a formalized methodology for the security assessment. The methodology should encompass the following: Planning: Decisions regarding assessment scope definition, staff and resource usage and assessment expectations should be developed, and documented in a project plan Information gathering: Available information regarding all organizational and operational aspects of the organization which fall within the defined scope should be gathered analyzed and used to develop assessment question sets Business process evaluation: Key business process owners should be interviewed, and key business processes should be tested, analyzed and documented; output information from this phase can be used to further refine or supplement the assessment question set Technology evaluation: Key technology owners should be interviewed, and key technologies should be tested, analyzed and documented; output information from this phase can be used to further refine or supplement the assessment question set Risk and gap analysis report: Security assessment, risk score calculations and gap analysis findings should be compiled in a report, along with control and mitigation recommendations . The security risk assessment stage is a critical component of the information technology compliance life cycle. If sufficient expertise and experience to conduct an assessment properly is not available in-house, organizations should seek the assistance of properly qualified and reputable consulting services. Step 3: Creating and implementing a set of policies and controls "Organizations must have a business-based security framework built upon leading practices that not only allow compliance with policy and regulations but also find a way to proactively identify risks, document compliance gaps, and report the state of the current security environment. The security framework must provide a sustainable process that allows for ongoing management of risks and compliance and must be built upon leading practices, accepted standards, contractual requirements, and applicable laws." Compliance flows from an organization's policies to its technologies (and not visa versa). In other words, if the compliance requirements state that protected information must be encrypted, then rather than worrying initially about how to manage encryption on each technology device, an organization should create a policy that sets encryption of protected information as a standard. Once these high-level, business-oriented policies are in place, then more specific plans and rules regarding implementation can be created in such a way as to be compliant with the higher level policy. In this way, an organization can get away from network and system level management, to higher level business policy management. If the standard policy configurations are always in compliance and being enforced, then only that standard needs to be managed. Any changes on individual technology devices will therefore leave that device either in compliance, or not (and action can be taken accordingly). Additionally, because the policies have been written using terminology such as "shal", 'should" or "must" to describe the desired state of operation, no room for misinterpretation or lag-time is left between discovering a problem and fixing it. Compliance policies should include business processes, business practices, and the security of both electronic and non-electronic resources. There is little point in having information encrypted on a hard drive, if it gets printed to a printer pool, or transmitted via fax to an insecure destination. Rather than creating policies which refer only to technology resources, it would be better to create a generic business-level policy such as; "Only authorized individuals may access business systems, resources or processes, and each system resource or process must have a corresponding list of authorized individuals". Such a policy would cover access to not just technology devices, but both electronic and paper documentation, and all business practices and processes used within that organization as well. Compliance controls are best implemented using centralized management. The rules that are developed internally by an organization's management are just as important as those developed externally by legislative bodies or regulators. The fact that the internally developed rules may not incur as heavy a penalty when not followed does not negate their importance to maintaining good business practices for that organization. So, it makes sense to collectively manage all rules (internal and external) at one time, and to do so using some type of centralized management system. Rather than trying to manage the configuration of firewalls one way, and configurations of routers and switches another; administer all technology devices from a central point of control by use of standardized templates. In this way, from an audit perspective, only the standardized templates need to be kept in compliance (as long as it can be shown that the devices are configurable only via the templates). Controls used should meet required industry and regulatory standards. They should be predictable and measurable, to allow for assessment and documentation. Controls can be physical (locks, security guards, badges, alarms, and similar measures to control access to technology), technical (safeguards incorporated in computer hardware, operations or applications software, communications hardware and software, and related devices), or administrative (such as management constraints, operational procedures, accountability procedures, and supplemental administrative controls established to provide an acceptable level of protection). These three categories of controls can be further classified as either preventive (attempt to avoid the occurrence of unwanted events) or detective (include audit trails, intrusion detection methods, and checksums). Finally, organizations should create plans, rules and configuration templates that are vendor neutral and support a broad range of manufacturer equipment. Not only will this allow the organization more flexibility in the technology solutions it can implement, but a more generic template is more likely to be better comprehended (and therefore approved, depending on the auditor) during an audit. Step 4: Monitoring, enforcing and documenting the controls At any point in time, an internal auditor should be able to compare whatever is being done, with what is supposed to be done. The advantage of this is that if an organization can have confidence that internal spot check audits show them to be in compliance, then they need not be that concerned with expending unnecessary amounts of time and effort in preparation for external regulatory audits. Given that much compliance management is manual with no reporting capabilities, and that which is automated often has poor reporting capabilities, it is recommended that along with centralized management, a high quality centralized reporting technology be utilized. Not only is this useful in terms of creating documentation for inspection during an audit, but it also gives an organization's management ongoing information concerning compliance states, tracking and accountability. Exceptions do happen. An organization's policy for production server connectivity may state that only SSL can be used, yet a senior manager within that organization may require the use of another secure protocol in order to perform their job function; but this change would now mean the organization is out of compliance with its own policies. However, the use of a documented change management process (which should include some sort of roll-back process if required) in which the proposed reconfiguration of a device may be reviewed, approved and implemented under the watchful eye of a change management body (which may range from a single manager to a committee), means that standard for compliance may also be amended and documented (the documentation should also give the name(s) of the manger(s) who have assumed the risk for this exception, and why). This way, the server connectivity remains acceptably secure, and in compliance. Whereas auditing catches some of the problems some of the time; enforcement detects and corrects out-ofcompliance states as soon as they occur. So, not only does enforcement mean an organization will be in compliance all the times, but also means that the very practices designed to protect the organization are in fact working. For example, an audit of an organization's firewall may show it to be in compliance. However, a subsequent change in the configuration (accidental or deliberate) may leave it out of compliance. By catching such an error, enforcement will protect the resource which compliance law is mandated for. The essential difference between auditing and enforcement is that the former serves the letter of the compliance law, and the latter the spirit. So, even though it is advisable that an audit should be conducted again any time there is a major change in the configuration of a technology to confirm a state of compliance still exists; enforcement is the only thing that ensures this. Conclusion Achieving and demonstrating information technology compliance is not an exact science. Different compliance laws and standards express varying levels of definition and guidance, and different individual auditors can have different expectations for the same aspect of compliance. Organizations should therefore strive to produce a standardized, if not formalized, methodology which should demonstrate reasonable due diligence and detailed documentation. Above all, achieving and demonstrating information technology compliance should not be viewed as a burdensome task, but rather as an opportunity to engage members of an organization in a proactive task of integrating key business strategies with mandated requirements, to produce a streamlined approach to the operation and management of their information technology resources. 1. Jones, D., (2005). The shortcut Guide to Network Compliance and Security. Realtimepublishers.com Inc. 2. Kairab, S., (2005). The Practical Guide to Security Assessments. Auerbach Publications Inc. 3. Herold, R., (2004). The Practical Guide to Assuring Compliance. Realtimepublishers.com Inc. |
 |
|
|
|
