During the Internet’s heyday, one of the new up-and-coming CxO positions (joining the CTO and the CIO) was the chief security officer (CSO). The logic was that someone was needed to deal with security concerns raised by increasing Internet integration. A CSO would essentially secure the company’s financial, technology, and information systems.
In many cases, companies implemented the CSO role as a mechanism to rein in all of the factions competing for control of security policies. After all, when the marketing department farmed out Web systems to outside hosting companies and put potentially sensitive company information on externally managed sites, who was responsible for setting standards? Who was there to make sure two departments sharing data between systems didn’t compromise security by passing the data back and forth as unencrypted text files?
Certainly, it made sense to give the responsibility for all of these issues to someone independent from the CIO or CTO so that the person’s judgment wouldn’t be impaired by political or technical infighting.
Great in theory, bad in implementation
However, those lofty goals of the CSO position never quite panned out. Most enterprises viewed the job as an extension of the responsibilities of its predecessor (most likely a network security admin) rather than a new role designed to respond to a new age of distributed systems.
The resulting CSO position continued to manage user ID and password policies—the physical and logical data access policies. Additional position responsibilities included the creation, management, and reporting of policies for Internet and e-mail usage.
After creating the policies and putting management systems in place, the CSO position in most companies faded into the background. That’s unfortunate, because there are a whole new series of security problems that continue to perplex IT staffs because there’s neither process nor a final authority to decide on important security issues.
The future of security
Where most security issues early in the Internet age revolved around a company’s exposure by allowing employees to go out to the Internet (where they downloaded viruses, sent out sensitive data, etc.), most future security issues will revolve around allowing other companies or individuals into the company.
For example, who defines the rules for how a company shares its data or systems with outside companies using technologies like Web services? With the ability to download and execute applications (not just browse Web sites) based on Java or .NET implementations, who decides what policies need to be in place to allow the business to use external applications without placing the company at risk?
Who’s responsible for the policies that determine how a company’s own developers sign and secure their code before distributing it to other companies (thus opening up a huge potential for litigation if the code turns out to be malicious or destructive)? Who decides how to share internal security credentials with external hosting companies for authentication and authorization to hosted company data by employees, partners, and customers? These are all issues that a CSO would own, except that most businesses have allowed the position to disappear.
Do you really need a CSO?
I’m not advocating that every company needs to have a CSO in order to resolve these difficult security issues. In fact, I believe very few individuals possess both the technical acumen and the business negotiation skills to handle this position effectively.
I do think, however, that most companies need to take a fresh look at how they handle security issues in a world of hosting companies, Web services, and Web applications that replace Web sites. As I’ve discussed these views with CIOs and MIS managers, they share my concern about new technologies “seeping through the cracks” of their existing security policies. There seem to be two schools of thought on how best to handle the situation.
This strategy seeks to divide security responsibilities by platform (mainframe, minicomputer, Web applications, distributed applications, workstations). In this scenario, the company creates a security committee, typically chaired by the CIO, composed of representatives from each of the key technology platforms. As a group, they decide on security standards and then have individual responsibility for coding and enforcing those standards on their platform.
Standards and methods
This strategy draws a clear line between the security standards and the methods used to implement the standards. Companies implementing this strategy want a single person to be held accountable for developing security standards and consider standards to be companywide and owned by a security officer, typically reporting to the CIO. (In many companies, the security officer will instead report to the CFO, adding a level of checks and balances to the organization’s security implementation.) The methods used to implement the standards are platform- or application-specific and are implemented and maintained by the individual or groups responsible for security on a given platform.
While it’s clear that most enterprises didn’t embrace the CSO position as the cure-all to solving the almost daily security issues that arise as new technologies are introduced, it’s equally clear that most companies haven’t settled on an alternate approach. Let me know how your company divides responsibility for security.