CSEC 630 Final Essay Questions

CSEC630 Final Exam Randy Rose

Page 1 of 13

1. Describe your technical recommendation for addressing the security

requirements in the overall technical design of the ABC Healthcare

network. This should include both internal and external (untrusted and

trusted) aspects. Untrusted would include user connectivity to the

Internet. The “trusted” network has the main purpose of supporting the

business functions of known entities (i.e. partners, suppliers, etc.) which

have a business relationship with the company. Note that you are to

concentrate on the physical and logical level, including the type of

hardware and software, however you are not expected to provide

specific low level details in terms of equipment suppliers or model

numbers, etc. for your recommended design. (30 points)

It is essential that ABC Healthcare meet its HIPAA, HITECH, and SOX regulatory

requirements. The best method for doing so is to build out a strong security posture

through layered defenses focused on maintaining information confidentiality, integrity,

and availability. There are two methodologies or frameworks that I think will help us

achieve this quickly and effectively. The first is commonly referred to as AAA or Triple A.

It is comprised of the overarching concepts of Authentication, Authorization, and

Accounting, which will allow us to judiciously control the data and resources on our

network (Rouse, 2010). AAA begins with strong policies and associated procedures for

network, device, and resource access and includes how such access will be granted,

modified, and terminated. In ABC Healthcare’s case, we have a Microsoft Active

Directory (AD) infrastructure, so all of our authentication is handled by the AD Domain

Controlling server, or DC. We have some password policies currently in place, but I

suggest an audit of all group policies and DC configurations against recommended

benchmarks from NIST (http://www.nist.gov) or the Center for Internet Security

(http://cisecurity.org/).

Due to many of our staff being medical providers and requiring access to shared devices,

I believe implementing a tap-and-go, single sign-on solution like Imprivata, which is

designed for health networks will increase security and reduce the risks associated with

poor password practices and open sessions. Using AD with Imprivata will ensure we’re

meeting the first two requirements of AAA for authentication (against AD’s LDAP

database) and authorization (through a combination of group policies and secure

credential passing) while not negatively impacting our users. The third piece of AAA,

accounting, will come from a combination of group policy-enabled audit functions, logs

from our packet capturing devices (which I describe below), and logs from our security

information and event management (SIEM) equipment. We don’t currently have a full

SIEM deployed. I recommend a solution like SolarWinds Log & Event Monitor for its

http://www.nist.gov/

http://cisecurity.org/


Page 2 of 13

reasonable price, great reputation, scalability, and compatibility with existing devices in

our infrastructure including our primary Electronic Medical Records (EMR) database,

Cerner. Other than deploying the Imprivata and SolarWinds appliances and installing

the tap-and-go readers at all the required terminals and workstations, no other changes

to network hardware or software should be required. Following AAA will ensure that we

all of our SOX requirements for maintain audit records and most of our HIPAA

requirements.

The second framework I suggest we follow is one that I have put together myself called

BRAVE. It is an acronym standing that encompasses the following key control areas:

Border Security;

Restriction of administrative privileges;

Application & Service Whitelisting;

Vulnerability & Patch Management; and

Encryption.

Border security includes all of the hardware and software controls that protect the edge

of the network, from hardware firewall and proxy appliances to tailored access control

lists (ACLs), DMZ device hardening, and any packet sniffers, such as Snort, that we

might wish to deploy to capture traffic entering and leaving the internal network. All of

our ACLs will need to be regularly audited to ensure that all of the correct networks,

VLANs, ports, and protocols are entered into the rules. Additionally, all of our ACLs

should be configure to explicitly deny traffic unless specifically allowed.

Restriction of administrative privileges means that we will need to make some changes

to user accounts. Almost all accounts created prior to 2010 and many created after 2010

are given local administrator rights to their workstations. This does not follow the

principle of least privilege, which states that a user should only be given the access

required to complete their job and no more. This also means we will need to remove all

generic or shared administrator accounts (such as those on our routers and switches)

and ensure that no actual administrators are using their admin accounts for non-admin

functions. Removing elevated privileges from standard users, removing generic admin

accounts, and restricting admin use to admin functions only could greatly reduce the

impact that an incident will have should one occur.


Page 3 of 13

Whitelisting is the process of denying access to everything that isn’t specifically allowed.

The Australian Signals Directorate saw an 85% decrease in successful cyber attacks

following the implementation of application whitelists, restriction of admin privileges,

and improved patch management (2014). Whitelisting can prevent unauthorized

software and services, such as malware, from running on ABC devices.

Vulnerability and patch management is an ongoing process for keeping all operating

systems and software up-to-date. We can use a configuration management product, such

as Microsoft’s System Center Configuration Manager (SCCM), but a better option, in my

opinion, would be to expand our SolarWinds suite and use their Patch Manager, which

patches both Microsoft products and most, if not all, of the third-party applications we

currently use. Some manual testing and deploying of patches will be required, which will

also require coordination of teams, but the addition of Patch Manager to our security

tools will greatly reduce the risk that any devices are falling far behind on their patch

levels.

The final step is encryption. Because a large proportion of our data is PHI, we need to

ensure that we have the adequate means to protect the confidentiality of that data. All of

our devices should have full-disk encryption with an industry-approved standard

algorithm, such as the Advanced Encryption Standard (AES). Additionally, any emails

going outside of the network should be examined by an email proxy and encrypted if

actual or potential PHI or PII is enclosed within the body of the email or the

attachments. As we operate primarily in the states of Virginia, Maryland, and North

Carolina, and the majority of medical organizations along the eastern seaboard use a

ZixCorp Encryption appliance, I suggest we do the same. This way, we will be compatible

with most of the insurance and other partner organizations with which we may be

exchanging PHI. Lastly, I recommend that we enable Public Key Encryption (PKI) both

internally and externally. Externally, we should purchase certificates from VeriSign or

another trusted provider. Internally, we can deploy our own Certificate Authority (CA)

and ensure that all of our servers are part of an internal web of trust by requiring all of

them to obtain certificates from the CA. Additionally, we can set users up with their own

digital certificates internal so they can digitally sign emails for non-repudiation and

integrity purposes.

If we follow these two frameworks, we will remain compliant for HIPAA and SOX, and

we’ll ensure that we’re well above the watermark for their security requirements.


Page 4 of 13

Furthermore, we’ll be protecting our shareholders from pricy breaches of systems and

priceless breaches of personal and private information.

References

Australian Signals Directorate. (2014). Strategies to mitigate targeted cyber intrusions.

Retrieved from http://www.asd.gov.au/infosec/mitigationstrategies.htm

Rouse, M. (2010). Authentication, authorization, and accounting (AAA). Retrieved from

http://searchsecurity.techtarget.com/definition/authentication-authorization-and-

accounting


Page 5 of 13

2. Discuss the way you will address requirements for system monitoring,

logging, auditing, including complying with any legal regulations. (10

points)

Both HIPAA and SOX have audit requirements that ABC Healthcare must meet to stay

compliant. HIPAA’s audit requirements are primarily concerned with regular and

continuous logging and monitoring of all systems that access or handle private health

information (PHI). SOX compliance requires that entities perform annual internal

controls assessments and that they collect logs with complete audit trails of financial

transactions (SOX-online, n.d.). In order to meet these requirements, I recommend

implementing the following control mechanisms:

Active Directory Audit policies;

A security information and event management (SIEM) system, such as

SolarWinds, ArcSight, or Splunk;

Network and host-based intrusion detection and protection systems; and

Data loss prevention software.

Active Directory Audit policies can be incredibly useful for troubleshooting issues and

responding to actual or potential incidents. However, they can also create administrative

overhead by pumping the logs full of too much information to be helpful. Therefore, it is

best that we only enable audit policies for high risk areas. My suggestions for enabled

audit policies are:

Logon failure;

Logon success;

Logoff success;

Other Logon/Logoff Events success and failure;

Credential validation success;

Process creation success;

Account lockout success;

Audit policy change success; and

Authentication policy change success;

An SIEM system combines a number of different security solutions into one easily

manageable interface and typically allows for real-time monitoring and analysis of

security and other events that are of concern to system administrators. SIEMs log an

incredible amount of information and can store that information for a significant


Page 6 of 13

amount of time, especially if we buy additional storage, such as a NAS. This will allow us

to use logs from months or even years back for audits and incident response. Depending

on the SIEM tool deployed, ABC Healthcare will be able to collect audit logs, changes to

hardware assets and software configurations, network and web traffic (including search

queries), mailbox archives, application debugging information, and more. An SIEM such

as SolarWinds Log & Event Monitor is a complete package solution with additional

components (including border protection appliances and network traffic analyzers),

while a product like Splunk is more of a log collection and querying tool. Whichever

SIEM we choose, we will easily meet compliance for both SOX and HIPAA audit and log

retention requirements out of the box. Since cost is not a major concern, my

recommendation is for the complete SolarWinds package, because it will allow us to

scale up without issue and it is compatible with our server architecture (which is nearly

all Microsoft Windows-based) and our EMR database. We can also create custom reports

for specific database concerns, such as multiple sessions for a single user.

With SolarWinds, we may not need an additional network-based IDS, however, I think it

would be prudent to instal a few Snort boxes at junction points throughout the network

to capture packets for later analysis. We can begin with just sniffing packets to see the

impact it has on overall network traffic, and later implement packet logging for writing

traffic to the NAS for later analysis. Snort also has a network intrusion detection system

(NIDS) mode which will perform smart detection on network traffic.

I also recommend looking into Cisco’s IPS for our Cisco devices. We already have a Cisco

ASA firewall appliance at the edge of the network. It may be compatible with Cisco’s

FirePOWER or other IPS solution, which can help us stop network intrusions as they

occur. For example, a slew of packets can come into our network that take advantage of

the fragment offset field in a teardrop attack and the IPS-enabled firewall can detect it,

discard those packets, and even block other traffic coming from the source IP. An IPS is

essential in stopping active attacks that we may not have metrics to detect and the data

collected by the IPS can be fed into our existing logs for further analysis.

The biggest risk for us and our patients is the loss of protected health information (PHI).

Data loss prevention (DLP) software can help us better protect PHI as it is stored locally

or when it is in transit off of our network whether via the web or over removable media.

RSA has a DLP product which scans various locations, such as shared and local drives,

looking for information we designate, such as social security numbers (SSNs), national


Page 7 of 13

provider identifiers (NPIs), insurance carrier numbers, credit card numbers, and

keywords from medical dictionaries, for example. We can combine these terms as well,

such as SSNs and names or NPIs and names and addresses. This will help us identify

where PHI or other personally identifiable information (PII) is kept on employees’

workstations. We can then use this information to formulate a plan for data protection

and retention (e.g., full-disk encryption on all workstations and disallowing storage of

files on local machines). Other DLP products will allow us to actively scan information in

files and set rules to determine if those files can be moved to removable media, email, or

a web browser.

References

SOX-online. (n.d.). Sarbanes-Oxley essential information. Retrieved from

http://www.sox-online.com/basics.html


Page 8 of 13

3. Describe how the system will identify and authenticate all the users who

attempt to access ABC Healthcare information resources. (10 points)

ABC Healthcare already has an LDAP backbone through Microsoft Active Directory for

administrating all user and group accounts. The major problem we face is that users

across the various group need to access devices differently, at different times, and for

different reasons. Most of internal support staff, such as the administrative personnel,

the web development team, bioenvironmental engineering, and the occupational health

folks, for example, use the same workstation all day, every day, respectively. Other staff,

mostly consisting of our medical personnel, including both doctors and nurses, and

many of our IT staff access multiple devices throughout their shifts. I propose a tap-and-

go, single sign-on (SSO) solution that ties into our existing database, such as Imprivata

OneSign (http://www.imprivata.com/). Imprivata OneSign will allow our medical staff

to use their existing proximity badge cards to “tap” into any workstation with a proximity

card reader and access their desktop, documents, and any of the applications to which

they’re authorized. We can customize session length to one shift (8 hours), half a shift (4

hours), or some other value. That means that the first time they tap in to a session, they

will have to input their password, but for the remainder of that session, they will only

have to tap the reader to authenticate, no matter which device they are tapping into.

An additional benefit to using Imprivata OneSign is that the tap-and-go feature does not

have to affect the remaining users, but we can still leverage its other functions. The

administrative staff and others can continue to log in to their workstations with their

usernames and passwords, so we won’t have to purchase proximity readers for all of the

support staff. However, we can still take advantage of Imprivata’s SSO features by

installing the Imprivata OneSign agent on their workstations. It will be a nearly seamless

transition, with the only major change being that they will now see an Imprivata logon

screen instead of their standard screen. OneSign can then pass the credentials to

whatever applications the user is attempting to access, including web-based applications

and those that do not are not configured to use the user’s LDAP credentials. OneSign has

a unique feature that can actually allow it to learn non-LDAP credentials and store them

for future use. The OneSign Agent is able to recognize login screens across various

languages and protocols. Additionally, with OneSign Anywhere, we can support all of our

non-Microsoft devices, including MacBooks, iPads, and even Android tablets (Imprivata,

2014).

http://www.imprivata.com/


Page 9 of 13

The last major upgrade to our EMR database allowed us to finally tie it to the LDAP

database for authentication and nearly all of our web applications are tied to LDAP, so

we’ll be able to integrate OneSign into the environment relatively effortlessly, which will

show create an immediate improvement in provider efficiency and thus patient

satisfaction, all while reducing IT administrative overload and increasing regulatory

compliance. The latter comes from us more easily being able to enforce password

compliance across all of our applications and databases. Interestingly, we should also see

a reduction in password-related risks as users will no longer need to remember or write

down their passwords to multiple sites or applications, since we can tie everything back

to their domain credentials. OneSign will also ease IT audit headaches through its audit

and logging capabilities.

OneSign can be managed via a virtual or a physical appliance. Communication between

the appliance and clients occurs over SSL port 443 and port 81, which uses a proprietary

security exchange protocol built around 128-bit AES with an Imprivata-generated unique

key-pair (Imprivata, 2013, p. 9). AES is the government standard symmetric encryption

algorithm, which means it is reliable and it plays nice with all of our existing

infrastructure. OneSign scales up easily, as we can always add more proximity readers,

and, if we so choose, we can add components as necessary to allow for finger biometrics,

facial recognition, USB tokens, and/or other authentication options. Lastly, we can get as

granular as we would like, from controlling how many sessions a user can have, which

devices they can log into, and even configure roaming virtual desktops for a single

session for our doctors and nurses on the thin client devices.

References

Imprivata. (2013). Introducing OneSign 4.8 [PDF document]. Retrieved from

http://www.imprivata.com

Imprivata. (2014). Imprivata OneSign Anywhere for healthcare [PDF document].

Retrieved from http://www.imprivata.com/sites/default/files/resource-files/2-

2014_OSA_HC.pdf


Page 10 of 13

4. Discuss how the system shall recover from attacks, failures, and

accidents. (10 points)

We need to adopt a policy of “uptime all the time, downtime anytime.” This will benefit

us in multiple ways, from ensuring that we can keep all systems patched and updated

without impacting users to being able to respond quickly and efficiently to cyber

incidents with minimal impact to users and patients. The key to building out this policy

is redundancy. Essentially, we need duplicate resources where possible and ensure that

parity exists for error correction. One major factor in maintaining recovery operations in

the event of an outage or failure is to ensure that we have a generator capable of handling

our entire core IT infrastructure at no more than 50% of the generator’s capacity.

It isn’t really feasible for us to have a warm or hot site for offsite recovery and we don’t

have any major partners outside of the local area where we can store critical recovery

data, such as backups. So, I suggest we store critical backup files in the cloud. We may

not be able to recover them right away if we lose power or Internet connectivity, but if we

are hit with a major virus or worm and data gets deleted, overwritten, or otherwise

corrupted, we can pull recovery files from the cloud. Our generator should keep our

internal services running in the event of a major power outage.

Our SIEM, IDS, and IPS should help us detect and respond to incidents quickly.

However, we need to develop an incident response (IR) policy so we can leverage those

tools in the most efficient manner possible. The National Institute of Standards and

Technology (NIST) has developed the Computer Security Incident Handling Guide,

which can serve as the backbone for our own plan. NIST recommends creating a policy

and plan, developing procedures to ensure that the policy and plan are carried out fully,

establishing communications guidelines with outside entities, establishing a team of key

players, developing communications guidelines for internal communication among the

members and other groups, finalizing what services the IR team will provide, and how

they will be sufficiently trained (Cichonski, Millar, Grance, & Scarfone, 2012, pp. 1-2).

They also recommend focusing on incidents over common attack vectors (p. 2), which is

easy for us, as we know that the primary threats are viruses and worms and the primary

target is PHI.

Prevention is key for us. By successfully deploying SIEM, IDS/IPS, and DLP products,

along with ensuring that our firewalls are locked down and our internal systems are

regularly patched and updated, we will have reasonable assurance that our technical


Page 11 of 13

controls are reducing the risk of successful attacks. We should also incorporate staff

security training and awareness into orientation and annual training requirements,

where we remind employees not to click links in emails, open attachments that they

weren’t expecting, and to ensure that they are encrypting all emails that contain any

patient information. We can also remind them of good password security and how to

avoid falling victim to social engineering attacks.

Should our training fall on deaf ears, we will be prepared to respond to cyber incidents

because we have established procedures in place. Our tools should be able to detect the

majority of events and incidents occurring on the network. Should we be alerted of an

incident, we can contain and eradicate as necessary, which can include shutting down

traffic on a specific port, calling a switchport down, or physically removing the device

from the network. A forensic investigation of the affected device can be done with the

right equipment. We will need a write blocker (sometimes referred to as a drive toaster)

and digital forensics software, such as FTK Imager or EnCase, which will allow us to

review the contents of the drive, such as the Windows Registry, the profiles of the users

on the machine, and the $UsnJrnl (which is the NTFS change journal). We may need

other tools, depending on the incident, but many of them are free or open-source, such

as Plaso (http://plaso.kiddaland.net/) for timeline analysis or PeStudio

(http://www.winitor.com/) for static investigation of Windows binaries. Keep in mind

that not all incidents will require a full forensic investigation. For known or common

attacks, we will most likely just wish to pull the device, reimage, and redeploy.

References

Cichonski, P., Millar, T., Grance, T., & Scarfone, K. (2012). Computer security incident

handling guide. NIST Special Publication 800-61, Revision 2. Retrieved from

http://csrc.nist.gov/publications/nistpubs/800-61rev2/SP800-61rev2.pdf

http://plaso.kiddaland.net/

http://www.winitor.com/


Page 12 of 13

5. Discuss how the system will address User Account Management and

related security improvements. (10 points)

As you’re already aware, we use Microsoft Windows Active Directory (AD) for user and

group management. My recommendation is to continue to use AD for user account

management but to audit all users and groups to ensure that we have no active accounts that

should be disabled or deleted and that every user is in the right groups. The audit should

look at our access control model, which is supposed to be role-based (RBAC), and determine

if we’re fully abiding by it. All staff are to be divided into logical groups in AD by their job

duties and departments. For example, all doctors and nurses are in the Medical Staff

organizational unit (OU) and then further broken out by department, such as Neurology,

Radiology, or Oncology. Administrative and other support staff are kept separate of medical

staff and are also divided up by job and department. The Information Services staff are

strictly divided by function, even within the same department due to the nature of their jobs

and the systems or resources to which they may have elevated privileges.

The AD audit will also need to look at Group Policies and how they are enforced throughout

the AD hierarchy. For example, several Group Policies, such as password policies, audit

policies, and Kerberos policies, will need to be administered at the domain level, not at the

OU level. Other access policies can be enforced at the OU level for users, groups, or even

device types. For example, we can set policies for Windows 7 users that are different than

those for Windows 8 users. We also need to ensure that the domain password policy is

enforcing password complexity, sufficient length requirements—I suggest more than 14

characters so the passwords are not stored in Windows LanManager—account lockout after

3-5 failed attempts, a password history of 24, and a password expiration of 90 days.

We recently upgraded our principle EMR database which has allowed us to tie it into the AD

structure, effectively letting us pass domain credentials to the database. I mentioned above

that we should look into Imprivata as a tap-and-go, single sign-on solution. Imprivata will

help us address account management across our various applications and databases, as it

passes AD credentials to the various programs. Imprivata improves account management

and security by allowing us to extend our RBAC model to those other programs. Imprivata

will attempt to pass credentials to the various applications but those credentials will be

rejected if the user is not authorized access by group policy. Imprivata will not allow a user

to bypass RBAC.

6. Complete the Cyber Security Action Plan template (30 points)


Page 13 of 13

CSEC 630 Final Essay Questions

Documents