IT folks used to have the corner on data protection because, long ago and far away, business technology was highly centralized and relatively easy to protect. However, over the past couple of decades, technology has exponentially increased in complexity and openness, creating new and unanticipated data protection challenges for IT leaders and practitioners that must be effectively addressed.
One of my earlier professions was as a systems analyst and programmer. At that time, in the late 1980s, data protection was relatively "easy." Most systems were closed systems. The network users were on terminals that just glowed green data at them on the screens and did not allow them to install any type of software or data into the network other than through controlled applications input screens.
A "closed system" with regard to a computer network is basically one that has no outside connections, and one on which the network users cannot establish outside connections.
The only feasible way in which end users could take any data off the system was through hardcopy printouts. It was common to use production data for test and development purposes. In fact, if you didn't use production data to test, it was widely considered that your testing would not be as comprehensive as possible and that you could not test for actual business purposes adequately. IT was very isolated.
Then came the 1990s and the legendary Novell NetWare servers that the business folks loved, ushering in distributed file servers that were managed by personnel in multiple business units outside of the corporate IT area. These servers provided new capabilities for end users to upload files and applications onto the corporate network. The corporate IT departments in most companies at first said, "Oh, we don't support those." So business units created their own IT teams to manage their own file servers. IT silos were born, scattered throughout the enterprise and very disconnected. Much confusion and uncoordinated computing ensued. Much of the latter 1990s was spent trying to get scattered file servers to talk with mainframes, and then to put them all behind firewalls to all Internet connections. The business units all viewed those activities as IT responsibilities, and they basically used what was given to them without really thinking much about information protection issues.
Then came Y2K, and even more types of technologies, and vastly more mobility. More mobile computers. More mobile storage devices. More mobile working. The silos and separation of IT from business lost effectiveness. Data protection lost effectiveness. IT areas became more important than ever for providing the safeguards for the enterprise data assets.
New technologies and practices will continue to grow over the next few years. Just think about all the new technologies widely used, and increasingly used, within organizations by the population at large, often without the knowledge of business leaders:
In addition to new technologies, mobile computing and mobile data (passing through networks as well as moving on human legs within mobile storage devices) must also be protected. But how can organizations do so effectively? How can IT do so effectively?
What is your IT area doing to protect the confidentiality, integrity, and accessibility of sensitive information that may be located in, or accessed by, these new technologies? You cannot provide effective data protection unless you know where data resides. In all locations. And in all forms. Safeguards are critical in all places where information is accessed and stored, both inside the corporate walls and, very importantly, in all locations outside the four walls.
IT leaders, administrators, developers, architects, and others who are the digital information custodians of the enterprise and are responsible for implementing security controls must understand the criticality and importance of their roles to ensuring data protection safeguards are effectively implemented and maintained.
A simple but effective roadmap for IT to follow to help them address important IT data protection requirements includes the following steps:
Perform information security risk assessments, preferably in conjunction with a privacy impact assessment (PIA), to determine and rank, as much as possible, identified IT risks. A common link within most compliance requirements is to establish controls that are appropriate for the organization's identified information security and privacy risks, so risk identification is a critical component of IT data protection activities, but is unfortunately too often overlooked.
When the information security, privacy, and compliance officers and/or the legal counsel direct the IT area to "Get the systems in compliance!" what should IT leaders do? They should identify common requirements throughout all the applicable laws, regulations, standards, and contractual requirements.
They should map the commonalities within a matrix that can then be used for easy reference to clearly see all the commonalities. Table 4.1 lists many, but far from all, the activities IT areas can perform to support compliance throughout the indicated laws and standard.
| IT Activities Supporting Compliance | Laws & Standard (See legend below) | |||||||
| A | B | C | D | E | F | G | H | |
| Enable system events (logging) | X | X | X | X | X | X | X | X |
| Log successful access attempts to mission‐critical resources | X | X | X | X | X | X |
|
|
| Make data backups |
| X | X | X | X | X | X | X |
| Establish access controls based upon job responsibilities | X | X | X | X | X | X | X | X |
| Require authentication | X | X | X | X | X | X | X | X |
| Encrypt personally identifiable information (PII) |
| X | X |
| X |
| X | X |
| Restrict inbound Internet traffic to the DMZ |
| X | X | X | X | X |
|
|
| Limit unsuccessful user ID login attempts after three consecutive unsuccessful tries |
| X | X | X | X |
|
|
|
| Implement tools to prevent malicious code attacks |
| X | X | X | X |
|
|
|
| Implement intrusion detection and incident monitoring tools | X | X | X | X | X | X |
|
|
Table 4.1: Windows server common data protection compliance requirements.
Legend
A—Sarbanes Oxley (SOX) Act
B—Gramm‐Leach‐Bliley Act (GLBA)
C—Payment Card Industry Data Security Standard (PCI DSS)
D—Federal Information Security Management Act (FISMA)
E—Health Insurance Portability and Accountability Act (HIPAA)
F—Fair and Accurate Credit Transactions Act (FACTA)
G—Canada's Personal Information Protection and Electronic Data Act (PIPEDA)
H—European Union's Data Protection Directive
This matrix may look slightly different from organization to organization. Go over this table with your legal counsel or information security department. Whether you need to undertake these activities for compliance will depend upon your own unique organization and your lawyer's interpretation of the law as it applies to your business and industry.
Once the risks and compliance requirements for data protection are identified, establish and implement appropriate controls. There are significant common core requirements across the many laws, regulations, and industry standards that organizations should recognize and use as keystones within their information security and privacy programs. IT leaders can use internationally‐accepted as well as industry standards to address the requirements in a unified way to reduce costs, save time, and increase the effectiveness and scope of information security and privacy programs. The following sections highlight common data protection activities that IT areas must undertake to provide the most effective data protection for electronic business assets.
Almost every data protection law, regulation, and standard requires that organizations be able to determine who has accessed sensitive business assets, such as PII, along with the details around that access. Not only is this a compliance requirement, it is a necessity for ensuring effective data protection.
Even if individuals have authorized access to network resources, organizations must be able to determine when those individuals used that access and what they did with it.
Another key component for data protection compliance is ensuring the availability of PII and other mission‐critical resources. IT must make backups of PII and related data to comply with availability requirements.
A common compliance requirement is to restrict access to applications, data files, and other network resources to only those who have a specific business need to have that access.
Across the board, laws, regulations, and industry standards require organizations to implement authentication, allowing only one person to use each user ID. They do so not only to establish accountability for access activities but also to be able to track and determine when individuals have been in systems with PII.
Laws in Massachusetts and Nevada, along with the recently implemented HITECH Act, require PII to be encrypted. Most other laws and regulations also list encryption as a PIIprotection method that organizations must consider. In addition, multiple regulatory oversight guidance documents encourage organizations to encrypt PII. Additionally, PCI DSS requires encryption in certain situations. IT should encrypt PII whenever possible to meet current and emerging legal, regulatory, industry standard, and contractual requirements.
Many data protection requirements advise organizations to establish barriers into the corporate networks from outside public networks, such as the Internet. For example, PCI DSS specifically states in Requirement 1, "All systems must be protected from unauthorized access from untrusted networks, whether entering the system via the Internet as ecommerce, employees' Internet access through desktop browsers, employees' email access, dedicated connection such as business to business connections, via wireless networks, or via other sources."
Some regulations, laws, and industry standards require user accounts to be locked after a specific number of unsuccessful attempts, such as six within PCI DSS. However, others require accounts to be locked according to best practices, such as indicated within NIST documents, which specify that accounts should be locked after three unsuccessful attempts.
Many data protection requirements specify that organizations must implement technologies and procedures to guard against, detect, and report malicious code. IT leaders must ensure up‐to‐date antivirus and malicious code prevention systems are implemented and appropriately managed.
Most data protection requirements indicate that organizations must implement tools and procedures to prevent network intrusions. For example, GLBA requires organizations to implement, based upon the results of risk analysis, intrusion detection and incident monitoring tools to be used for "detecting, preventing and responding to attacks, intrusions, or other systems failures."
By implementing a core set of controls throughout the enterprise network and computer devices, IT can help the organization meet compliance with numerous applicable laws, regulations, and industry standards. The bottom line to make IT compliance responsibilities and activities as effective, efficient, and manageable as possible is to:
It is important to establish IT requirements and manage data protection technologies to support business as well as to address compliance. When IT leaders ensure a comprehensive, risk‐based data protection plan is implemented, they will avoid many common IT blunders. Let's consider just a few of them.
Privacy breaches involving production PII used for test and development purposes are increasing in number, as are the associated risks. Additionally, legal restrictions against using production PII for test and development purposes are on the rise and increasingly being enforced.
IT test environments are inherently less secure than in production because data is typically exposed to a wider variety of "insider" sources without a clear business need for access, including in‐house testing staff, outside contractors and consultants, partners, and increasingly offshore development shops. Although many of the incidents by insiders is a result of malicious intent, a large number of breaches is caused by the developers being unaware of the basic security that needs to be in place, or as a result of accidents and negligence. No matter the reasons, these insider incidents can be very costly to both the company and the individuals involved.
Consider just one of the many incidents where privacy breaches resulted from using production PII for test and development. In June 2006, a programmer hired to create an application for the Sentry Insurance Company in Wisconsin was sentenced to 60 months in prison and fined $519,859 for attempting to sell more than 111,000 individuals' Social Security Numbers and other PII to an undercover US Secret Service agent. The programmer had taken the data from the insurance company where he was working as a business software consultant and had been given the data to use for development and testing. The programmer had also sold the data to others before being caught.
Test data is vulnerable to not only malicious intent but also basic unawareness and mistakes. A couple of years ago, an e‐discovery company was at a conference I attended and giving a demonstration of their product to a large number of folks in the vendor exposition area. The data they were using was the actual sensitive employee and customer PII from one of their large clients. Following the presentation, the vendor reps told me they hadn't thought about the privacy or legal issues involved with using actual PII.
Multiple studies confirm that the insider threat is the cause of the majority of information security incidents and privacy breaches that occur. The current abysmal US economy provides even more motivation for insiders with access to sensitive information to purposefully do bad things. A December 2008 report by IBM's ISS X‐Force research team reported a 30% increase in network and Web‐based security incidents during the last half of 2008, much of this increase attributed to economic fear.
Another December 2008 report by Cyber‐Ark Software also confirmed this upturn in insider‐caused incidents. It reported 56% of workers are worried about job loss, and that 58% of U.S. workers said they have "already downloaded competitive corporate data and plan to use the information as a negotiating tool to secure their next post." 71% indicated that if they were laid off, they would definitely take company data with them to their next employer, with the most likely data being "customer and contact databases, with plans and proposals, product information, and access/password codes."
Most data protection laws throughout the world are designed to protect the privacy of individuals by placing significant and specific restrictions on the ways in which organizations can use PII. For example, any organization that collects PII from citizens in the 27 EU countries must abide by Data Protection Directive 95/46/EC and any additional restrictions each member country has established.
It is common for organizations to use PII in ways that breach the EU Data Protection Directive requirements. The financial consequences of such breaches can be significant, and if a security incident occurs that results in PII being misused, the consequences are dramatically increased.
These restrictions, as well as the restrictions in most data protection laws outside the US, are based upon eight privacy principles. The principles that are directly applicable to restricting use of PII for test purposes include the following:
The bottom line is, to comply with worldwide data protection laws, it is most effective for IT developers and testers to not use PII unless it has been de‐identified or masked. In circumstances where using PII is unavoidable, the quantity of PII should be reduced to the bare minimum necessary for testing. When a third party does development and/or testing, make sure the appropriate contracts and safeguards are in place.
It is often helpful to look at the information security incidents that have actually occurred to try to identify the possible reasons things went wrong, then use those lessons to implement controls within your own organization to keep similar incidents from occurring. The following sections highlight case studies that demonstrate the importance of IT controls for data protection.
In May 2008, Lending Tree got slapped with a civil suit alleging their personnel allowed mortgage lenders access to customers' PII and other confidential information because of poor application controls, which required customers to access their personal account information online using a user ID and password (single‐factor authentication). The suit charged that Lending Tree did not have appropriate or adequate information safeguards in place, resulting in the lenders using customer names, addresses, phone numbers, Social Security Numbers, income information, and assorted other personal information, to market their own mortgage loans to the Lending Tree customers. What are some IT controls that can be used to prevent employees, contractors, or anyone outside of the organization for that matter, from accessing and stealing sensitive customer information?
These are just a few of the ways in which the risks could be mitigated. What other IT controls can you think of?
In March 2008, the presidential candidates' passport files were widely reported as being breached on government computers because they were inappropriately accessed by contracted workers, who then are suspected of sending the files, or file details, to others. The State Department's computer system had flagged each incident, but IT did not notify senior department officials until after reporters asked the senior department officials if the files had been improperly accessed. There were many information security and privacy issues involved with this incident. Some questions that IT personnel could answer include:
IT operations leaders can dramatically improve upon information security for their electronic systems, applications, and data by incorporating information security and privacy checks, controls, and safeguards throughout the entire systems and applications life cycle. By identifying risks at each stage and then implementing the appropriate security controls to address them, the result will be a much more secure digital enterprise.
When making a decision about implementing or updating a system or application, think about and document the related data protection requirements. Typical objectives for this phase include:
Key IT data protection activities:
When identifying the business requirements, keep in mind any related data protection and privacy issues. A business requirements team will typically be involved that should have the business requirements documented. The typical objectives for this phase include:
After the business requirements have been determined, it is time to start digging deeper into details for the functional specifications. This point is critical for identifying IT security and privacy issues. Unfortunately, such issues are often not considered during this phase, leading to unsafe applications and systems after they have gone into production. The typical objectives for this phase include:
Key IT data protection activities include:
After knowing the functional specifications and identifying the related technologies, IT can identify the technical specifications and designs necessary to support them. The typical objectives for this phase include:
Key IT data protection activities include:
Once the technical specifications and plans are finalized, it is time to start coding. A different team than the one that created the technical specifications typically does the coding, so it is critical that the IT information security and privacy specifications are comprehensive and clearly documented in the previous phase. The typical objectives for this phase include:
Key IT data protection activities include:
Testing is critical for information security and privacy due diligence in the IT areas.
Comprehensive tests, as identified and documented in the previous phase, must occur. Typically, a different team does the testing than those who created the code and the test cases. It is important that those testing have a good understanding of information security and privacy concepts so that they know problems when they see them, so ongoing training and awareness for this group is essential. The typical objectives for this phase include:
Key IT data protection activities include:
Data protection cannot be effective unless information security and privacy testing is an integral part of the software testing process. Comprehensive information security and privacy testing during development enables IT to identify functional issues early, when they are easier and less expensive to fix.
After thorough testing, it is time to plan for a smooth deployment. This critical point often reveals significant security and privacy problems that were not properly addressed during development. Such oversights have often resulted in significant security incidents and privacy breaches. The typical objectives for this phase include:
Key IT data protection activities include:
After the application and/or system has been put into production, and ongoing support and maintenance has been passed on to a different team, the development team needs to review the project and determine the things that worked well, as well as the things that need improvement. The typical objectives for this phase include:
Key IT data protection activities include:
The day‐to‐day IT maintenance and operations teams now must work to ensure the applications and systems continue to work smoothly as intended as well as be on the alert for any potential problems. The typical objectives for this phase include:
Key IT data protection activities include:
Retirement is another of the commonly overlooked phases when it comes to information security and privacy due diligence. Don't slack off and just throw away security and privacy when a system, application, or storage devices is retired and no longer used! The typical objectives for this phase include:
Increasing numbers of laws, regulations, industry standards, contractual obligations, and organizational policies require information security and privacy practitioners to view their job responsibilities as including compliance enforcement activities. Growing fines, penalties, and other types of sanctions make it increasingly important to implement comprehensive enterprise‐wide information security and privacy practices.
When IT uses a unified approach to information security and privacy compliance, organizations can more effectively manage the growing number of compliance requirements. A unified IT approach to information security and privacy compliance allows organizations to not only address identified risks but also comply with legal requirements.