There are three high-level roles in managing information security: business leaders, technical leaders, and information security auditors. Business leaders are responsible for defining business policies related to information security. Technical leaders are responsible for accurately enforcing business policies in various technical environments. Security auditors are responsible for ensuring that business policies are adequate and determining whether various technical environments have accurately enforced business policies.
Unfortunately, in a great majority of cases, either people in the wrong roles try to fulfill these responsibilities or the people in those roles are not meeting their responsibilities. At least this has been my experience with numerous customers.
Given this state of affairs, is it really any wonder that managing information security seems to be so complex?
Information Security Management Only Appears Complex
Typically, upper-level managers believe information security is the primary and sole responsibility of the IT organization. This is born of the mistaken assumption that security is a black-and-white proposition, that there is one right way to secure electronic business assets properly and only people with the proper technical background know this one right way. From their point of view, information security requires finding the right technical expertise to "do the right thing." This perspective is also driven by the assumption that, unless they understand the deep, dark secrets of computer technology, they really are unable to participate usefully in the security process.
This leads directly to the dismal state of information security across the entire industry today. Why? Because it results in business decisions made by technical people driven primarily by technical assumptions, which themselves are often invalid.
Before the "information age," file cabinets were used to manage information. The facilities department owned the file cabinets. In today's world, making the IT organization responsible for making decisions about who can access which information is analogous to leaving those same decisions to the facilities department!
In effect, management abdicates its responsibility for defining business policy to the technical personnel in the IT organization. These people, typically, have neither the appropriate business background nor the actual legal responsibility for making those decisions. Very often, the result of this approach to information security is the enforcement of inadequate business policies defined, by default, by technical people. For example, do all employees in the accounting department and the finance department need access to all of the company's financial and payroll information? The system administrator in the IT department should not be making this sort of decision! It is not his or her responsibility, and typically, system administrators lack the business background to make an appropriate decision.
Even if the appropriate people in the company are involved in defining policy, system administrators are often solely responsible for choosing the "right way" to enforce those policies. In the absence of appropriate business guidance, logic such as "we can't do that because it's too expensive" or "doing it this way is good enough" drives the technical enforcement decisions. While the logic is valid when made in the context of a business decision, the determination of "too expensive" or "good enough" is purely a business decision. When technical people make decisions based on this kind of logic, in effect, they are making business policy decisions. This, in turn, leads to unintended exposures and vulnerabilities…and to incidents not unlike the TJX fiasco alluded to earlier.
Both business and technical leaders often misunderstand the term "policy." "QSECURITY must be set to 40" is not a security policy; it is a security procedure. Procedures (sometimes referred to as processes) document the technical configuration a company has chosen to enforce business policy. Policies, on the other hand, are statements that define who (in terms of employee roles) is allowed to access which business assets—at an abstract level, not in terms of computer objects—for which business reasons.
The Sarbanes-Oxley (SOX) legislation says nothing about how business should enforce policy. It defines certain policies that public corporations must adopt. Probably the most important aspect of SOX is that it clearly makes high-level management legally responsible for ensuring the adoption of appropriate business policies and the accurate enforcement of those policies.
Effective Management of Information Security
The proper role of technical personnel is to configure a system to accurately enforce the policies defined by the business leaders. It is their responsibility to assess the cost to enforce policy accurately but not whether that cost is either acceptable or too high. The IT organization should determine the best technical approach to enforce a policy, not whether a policy will or will not be enforced accurately. Business leaders are supposed to use input from the IT organization to determine whether to change a policy, grant an exception to a policy, or seek additional technical expertise—internal or external—to identify acceptable alternative technical solutions for enforcing the policy. The best technical approach to enforcing policy is the one that accurately enforces policy for the least amount of cost over time.
This is how business should manage information security. Business leaders do not require a technical background to play an appropriate and indispensable role in information security.
The Information Security Management Business Process
The proper management of security requires a business process, just as the proper management of revenue and profit require a business process.
Anyone who has taken Management 101 knows the standard business process model:
- Define the requirements and objectives.
- Plan the implementation of the solution for meeting those requirements and objectives.
- Implement the solution.
- Measure the effectiveness of the solution in terms of the requirements and objectives.
- Feed knowledge and experience gained back into step 1. Repeat the process.
The security management business process follows this model precisely. When the appropriate roles in the organization execute the various steps, the result is effective and cost-efficient information security management.
Now, I will define the responsible roles, the inputs, and the outputs for each step.
Define the Information Security Requirements and Objectives
The outputs of this step are business policies, defined at an abstract behavior level. In addition, these policies are used to measure the accuracy of the technical implementation of the enforcement of these.The ultimate responsibility for this process step rests with high-level management. In public corporations, SOX legislation makes certain corporate officers legally responsible. In most organizations, high-level management will delegate this responsibility to a CIO or Director of IT, and rightly so. Whatever the role of this person in the organization, he or she is responsible for driving the entire process and for executing this particular step of the process. This person must put together a team that includes all of the right skills. The most important consideration is that, along with the responsibility, management also delegates the authority necessary for this person to accomplish this task.
Technical personnel in the IT organization also have an important role to play in this part of the process. However, it is advisory in nature. They should not own this task or be responsible for driving it. If the team is contemplating establishing a policy that is obviously technically unenforceable—"All employees must wash their hands before touching a keyboard," for example—their role is to make this known to the entire team.
The legal department also has a role in this step. Depending on the industry in which the company operates and whether or not the company is a publicly traded corporation, there will likely be legal considerations related to requirements. Other requirements—employee rights, etc.—will also dictate decisions related to business policy.
Organizations may determine that they require additional business expertise to execute this step. Get business expertise, not technical expertise! You need someone who understands your industry and legal responsibilities, not someone who knows the most efficient way to manage user IDs!
The inputs to this step are requirements—legal, ethical, and moral—that arise from the industry in which the company competes, as well as federal and state laws.
Plan the Implementation of the Solution Necessary to Meet Those Requirements and Objectives
The outputs of this step are the processes and procedures used to enforce business policy in various IT environments.It may surprise some that this is primarily a business decision, not a technical decision. Security is a function of both risk tolerance and cost. As such, business leaders have the final authority for determining whether a proposed technical solution is cost-effective.
Again, technical personnel play a very important role in executing this step. It is their responsibility to identify and define both the "best" way to technically enforce business policy and the projected cost of that approach. The best way, as mentioned previously, is the one that both accurately enforces business policy and costs the least to implement and manage over time.
It is impossible for any one person to know the most effective and efficient way to enforce all policies. Effective execution of this step requires understanding that if what appears to be a rational business policy seems to be too costly to enforce, then the organization needs to find additional technical expertise to determine whether other approaches exist that are both effective and cost-efficient.
It is also important to consider how the configuration itself will be monitored and enforced. Without doing so, it is inevitable that the configuration will drift away from enforcing the defined business policies. Take, for example, a production outage of a critical application. The person on call for supporting this application finds that giving PUBLIC *CHANGE to every object fixes the problem. While this might well be acceptable to get the business running, it is not acceptable to leave it this way. You need to include in your enforcement processes and procedures descriptions for how you manually or automatically ensure that what you configured six months ago is the way the environment is configured today.
It is this point in the process that third-party security solutions should be considered. Security solutions should be purchased only when there is a clear business case that purchasing that solution will result in reducing the cost of implementing and enforcing your business policies. Despite the sales claims of numerous security solution vendors, no specific product is required to enforce business policies. There are always technical alternatives. You purchase third-party products when they will help you enforce your business policies more effectively and cost-efficiently than the other alternatives.
The inputs to this step are the policies defined in the previous step.
Implement the Solution
The outputs of this step are the appropriate implementation and configuration of technology for the various environments. This is solely the responsibility of technical personnel in the IT organization.The outputs of this step are the accurate and cost-effective enforcement of business policy.
Measure the Effectiveness of the Solution in Terms of the Requirements and Objectives
The output of this step is verification of the accurate enforcement of business policies in the technical environment.This is the responsibility of information security auditors—both internal and external.
To provide any real value, external or third-party security audits must start by assessing the adequacy of the business policies. Business policies define what "properly secured" means in your environment. Thus, they are the only metric by which an auditor can determine whether you have properly secured your assets. The proper role of an external auditor is to determine if the business policies are adequate and then to determine whether systems and networks accurately enforce those policies. If a business policy allows accountants to use the HR application and to access private employee information, the policy is out of compliance, not the system that is configured to enforce the policy. The policy must be changed first and then the enforcement of the policy must be changed. If business policy does not define a need for accountants to access private employee information, but a system allows it, then the system is not accurately enforcing business policy. The company is not out of compliance, per se; it is simply not accurately enforcing its own policies.
If the security management business process has been executed effectively, an internal audit can rely on the outputs of the implementation-planning step as compared to the actual configuration in a specific environment. Internally, there is an implicit assumption that the process has produced business policy necessary to secure business assets and to be compliant with industry and government regulations.
The inputs to this step are the outputs of the all of the previous steps.
Feed Back the Knowledge and Experience Gained into Step 1 and Repeat the Process
Invariably, execution of the process will bring to light new, more efficient or effective ways to enforce business policies. This newfound knowledge and understanding will be valuable as inputs for the ongoing security management process.More Than Technology
Effective security management requires much more than technical expertise. In fact, it requires as much or more business expertise. Security is a function of risk mitigation and cost. There is no one right way to technically enforce a particular policy. The right way is the one that is both accurate and cost-efficient. Given any two organizations, it is highly likely that they will arrive at different technical enforcement of similar policies. The security business management process provides the framework for your organization to arrive at the best solution for you.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online