Case Studies and Examples of IT Infrastructure Security Policies

The case studies in this section examine how industries and state governments develop and implement infrastructure security standards. These case studies illustrate the influence that industry standards have on internal infrastructure policies. These examples reference leading industry standards to create and implement internal policies. This approach is true for both private and public sector.

State Government Case Study

In 2019, a coordinated attack was launched against government agencies in the State of Texas. Twenty-three state government services were affected, including police departments. The attackers were seeking $2.5 million in ransom.

The first infrastructure issue to address is email. Ransomware is most often delivered as an email attachment. This ransomware was not detected by any of the agencies’ email antivirus programs. Furthermore, various individuals were willing to open the attachment, and thus infect the organization.

The particular ransomware encrypted the files and added a .JSE extension. It is generally referred to as the .JSE ransomware. This is not a currently known strain of ransomware; however, it was delivered to the systems using the Nemucod Trojan. Nemucod is a well-known Trojan. It typically is distributed as JavaScript embedded in a Zip file attached to an email. The emails are usually socially engineered to increase the likelihood of them being opened.

Some reports have indicated a common managed service provider may be the issue. Whether or not those preliminary reports ultimately are determined to be accurate, they do bring up a valid concern. When several organizations have a single point of contact, such as a managed service provider, that point of contact becomes a very enticing target.

There are several items that could have mitigated this attack:

  • More effective policies regarding attachments.
  • The common security concept of never trusting any data, regardless of environment, should have been applied to the managed service provider as a policy.
  • Effective policies regarding employees recognizing social engineering. This can be accomplished by training.

This particular case study is important because all indicators show that ransomware is on the increase. In 2019, several cities in the United States were hit with ransomware attacks. Most analysts predict this will continue.

Public Sector Case Study

The State of Maryland initiative is an example of external influences on infrastructure security policies. The governor of Maryland created a “Best in the Nation Statewide Health Information Exchange and Electronic Health Records” initiative. The state created a statewide technology infrastructure to support the electronic exchange of health records. This infrastructure supports health service providers doing business in Maryland. The goal of the initiative is to reduce costs and improve the quality of patient treatment.

The Information Technology Support Division (ITSD) is the state’s IT department. The Department of Health and Mental Hygiene (DHMH) was responsible for meeting the governor’s health goals. ITSD was responsible for the technology aspect of the initiative. The ITSD was already supporting the DHMH technology environment.

Some of the core ITSD requirements include:

  • Expand network performance and capacity.
  • Provide continuous operations.
  • Provide a secure infrastructure.
  • Provide remote access.
  • Provide real-time access to patient medical information.

DHMH developed a staged implementation strategy. The strategy starts with pilot applications. After assessing performance and security, the pilot applications evolve to fully functional operations. This includes ITSD providing continuous security support.

This government initiative directly impacts infrastructure policies. ITSD is responsible for developing and maintaining information security policies, standards, and procedures for DHMH. This new infrastructure affects state-owned computing environments. Although this is not implicitly stated, any private company wishing to participate in and access this network must also adopt these infrastructure standards.

This is also a good example of not reinventing the wheel. It’s reasonable to assume that ITSD based the new statewide policies on the Health Insurance Portability and Accountability Act (HIPAA). HIPAA can be viewed as the core security control standards. The implementation of these core controls results in numerous baseline standards for the state’s new infrastructure, such as new and modified LAN and WAN security standards.

Critical Infrastructure Case Study

Televent is a company that provides software and services to monitor and support the energy industry in the United States and Canada. On September 10, 2012, the company identified a breach of its internal firewall and network. Televent said the hacker installed malicious software and stole software related to its core offering used by its customers. This is a class of software known as “supervisory, control, and data acquisition,” commonly called SCADA. SCADA systems are vital components in managing and controlling of power grids.

These types of successful attacks highlight how vulnerable power grids, and thus the national critical infrastructure, are to hackers. SCADA networks were built originally as closed systems, but over time devices with Internet access have been added to the SCADA networks. For example, individual desktops have Internet access and access to business servers as well as the SCADA network. This makes the SCADA system vulnerable to Internet threats.

In this case, Televent reported that it had disconnected the usual data links between clients and segmented the affected portions of its internal networks.

As with many breaches, the technical details may never be known to the public; however, it is clear that the existing infrastructure policies were not adequate. The measures taken in the breach announcement indicate a lack of adequate policy and/or enforcement in at least these two areas:

  • Network segmentation
  • Separation between production and test environments

Network segmentation was introduced immediately to isolate the customer support systems from those infected by malicious software. This raises the question of why such segmentation wasn’t included as part of the LAN policy in the first place. Such a policy would have ensured the creation of a closed network of people, processes, and technology for the systems providing direct access to the customer network.

It is unclear if the malicious software was placed on production or test systems. Separation between production and test systems is an important control. In this case, the need to segment the network immediately and the loss of software code are good indications that both test and production systems were vulnerable. This would be an indication of a potential lack of control between the test and production environments. System and application domain policies not only should be segmented, but also should highly restrict access between these two environments.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.139.79.233