CSIA 485: Practical Applications in Cybersecurity Management & Policy Project #5: Implementation Plan Instructions This assignment requires that you adapt the analysis done for Projects #1 - 4 to a new environment. Use your prior work, i.e. the recommendation memo and network diagram, to develop a high-level plan for implementing an infrastructure that includes the required controls, changes, etc. to mitigate vulnerabilities and convergence issues in the second case study’s environment. You may need to do additional analysis to address issues specific to the second case study’s environment. Your high-level plan should include all the system development life cycle (SDLC) gates/decision points and all relevant tasks. Describe and relate the implementation solution to CIA and incorporate, people, processes and technology to this plan. Note: Make sure that you include (in detail) the steps you would take to secure the new infrastructure. Putting It All Together Your plan will be a combination of a paper and a detailed list of steps and resources that you would follow to implement and complete this project. Think about all of the actions, resources, and tasks that you would need in order to effect a successful implementation. These should also be included as part of the plan. The minimum structure for this assignment is below: • • • • • • INTRODUCTION o Purpose of Plan GOALS AND OBJECTIVES o Business Goals and Objectives o Project Goals and Objectives SCOPE o Scope Definition o Items Beyond Scope PROJECTED EXPENSES o System Development Life Cycle/Schedule o Milestones ASSUMPTIONS o Project Assumptions CONSTRAINTS o Project Constraints o Critical Project Barriers Copyright © 2018 by University of Maryland University College. All rights reserved. CSIA 485: Practical Applications in Cybersecurity Management & Policy Additional Information 1. Consult the grading rubric for specific content and formatting requirements for this assignment. 2. Your 5 – 8 page Implementation Plan should be professional in appearance with consistent use of fonts, font sizes, margins, etc. You should use headings and page breaks to organize your paper. 3. Your paper should use standard terms and definitions for cybersecurity. See Course Content > Cybersecurity Concepts Review for recommended resources. 4. The CSIA program recommends that you follow standard APA formatting since this will give you a document that meets the “professional appearance” requirements. APA formatting guidelines and examples are found under Course Resources > APA Resources. An APA template file (MS Word format) has also been provided for your use CSIA_Basic_Paper_Template(APA_6ed,Nov2014).docx. 5. You must include a cover page with the assignment title, your name, and the due date. Your reference list must be on a separate page at the end of your file. These pages do not count towards the assignment’s page count. 6. You are expected to write grammatically correct English in every assignment that you submit for grading. Do not turn in any work without (a) using spell check, (b) using grammar check, (c) verifying that your punctuation is correct and (d) reviewing your work for correct word usage and correctly structured sentences and paragraphs. 7. You are expected to credit your sources using in-text citations and reference list entries. Both your citations and your reference list entries must follow a consistent citation style (APA, MLA, etc.). Copyright © 2018 by University of Maryland University College. All rights reserved. Journal of Information Technology Education: Innovations in Practice Volume 11, 2012 Disaster at a University: A Case Study in Information Security Ramakrishna Ayyagari and Jonathan Tyks University of Massachusetts-Boston, Boston, MA, USA r.ayyagari@umb.edu; downtime6@gmail.co Executive Summary Security and disaster training is identified as a top Information Technology (IT) required skill that needs to be taught in Information Systems (IS) curriculums. Accordingly, information security and privacy have become core concepts in information system education. Providing IT security on a shoestring budget is always difficult and many small universities are challenged with balancing cost and effectiveness. Many colleges and universities have additional security challenges, such as relaxed working environments, less formalized policies and procedures, and employees that “wear many hats.” Therefore, it is not surprising to note that majority of data breaches since 2005 occur in educational settings. So, it is imperative that this segment (i.e., educational settings) be represented in classroom discussions to prepare future employees. To this end, we present a case that addresses a data breach at a university caused by lax security policies and includes an element of social engineering. The data breach at the university resulted in a number of students’ losing personally identifiable information. The resulting aftermath placed a significant financial burden on the university as it was not prepared to handle an information security disaster. This case can be used as a pedagogical tool as it uniquely captured a data breach in a university setting. Readers of the case will identify that at the management level the case raised a number of issues regarding the security culture at the university and management of security function. The case also highlights the issues of lack of training and access control. Keywords: Information Security, Disaster Recovery, Data Breach. Introduction Security and disaster training is identified as the top IT required skill that needs to be taught in IS curriculums (Kim, Hsu, & Stern, 2006). Accordingly, information security and privacy have become core concepts in information system education (Hentea, Dhillon, & Dhillon, 2006; Kroenke, 2012; Laudon & Laudon, 2010). Instructors have several approaches to teach security and privacy concepts. One can take a more traditional lecture based approach or a more hands-on approach that utilizes labs, case studies, etc. (Gregg, 2008). It is important to note that advances in pedagogical research place emphasis on Material published as part of this publication, either on-line or hands-on or active learning. Imparting in print, is copyrighted by the Informing Science Institute. knowledge based solely on lectures is Permission to make digital or paper copy of part or all of these criticized as there is less opportunity for works for personal or classroom use is granted without fee students to be actively engaged (Bok, provided that the copies are not made or distributed for profit or commercial advantage AND that copies 1) bear this notice 1986). in full and 2) give the full citation on the first page. It is permissible to abstract these works so long as credit is given. To copy in all other cases or to republish or to post on a server or to redistribute to lists requires specific permission and payment of a fee. Contact Publisher@InformingScience.org to request redistribution permission. Accordingly, active learning has gained prominence among educators and researchers (Meyers & Jones, 1993). Students are eager and seek opportunities to Editor: Uolevi Nikula Information Security Disaster apply their knowledge to simulate realistic situations (Auster & Wylie, 2006). Research shows that students find learning achieved through active participation to be more meaningful and valuable (Mitchell, 2004; Pariseau & Kezim, 2007; Wingfield & Black, 2005). One of the ways in which students can be engaged is through case studies (Bradford & Peck, 1997; Shapiro, 1984; Pariseau & Kezim, 2007). Case studies provide the students a unique opportunity to assume the roles of participants in the cases (Richards, Gorman, Scherer, & Landel, 1995). This provides an opportunity for students to reflect on their learning and apply it to crystallize their thoughts and arguments. Students are put into situations that can be ambiguous and force students to make decisions dealing with uncertainties (Richards et al., 1995). In fact, a recent study about learning preferences indicates that students place high value for case studies (Goorha & Mohan, 2009). Raising awareness regarding security issues faced by educational institutions is important because the majority of reported breaches occur in educational settings. An analysis of all the data breaches from 2005 indicates that 21% of breaches occur in academic settings resulting in more than 8 million individual records being compromised (Privacy Rights Clearinghouse, 2011). It should be noted that the ‘education’ industry has the most number of breaches compared to any other industry category including medical, businesses, and government agencies (Privacy Rights Clearinghouse, 2011). Further, fundamental differences exist between academic and business settings. It is common practice in businesses to protect trade secrets, intellectual property, etc. However, educational settings are based on values of information sharing. As Qayoumi and Woody (2005, page 8) point out, “…the concept of information security runs counter to the open culture of information sharing – a deeply held value in academe.” Therefore, it is important to raise awareness about the severity of security issues facing university settings. However, a brief review of published cases in prominent outlets reveals that typical cases are geared towards business settings as presented below. Literature Review of Security Case Studies Most of the prominent security case studies focus on how businesses deal with data breaches or privacy issues. For example, McNulty (2007) discusses the impact of a data breach on customers in a retail electronics setting. The case deals with issues of the best way to communicate the breach with customers and, overall, forces the participants to consider disaster response strategy before a disaster occurs. Similarly, Haggerty and Chandrasekhar (2008) highlight the events leading to and the fallout due to a data breach at TJX. These cases highlight the issues of enormous amount of data that retailers generate and the onus on firms to protect the sensitive information. Eisenmann’s (2009) case addresses the severity of growing dependence on technology in the medical industry. The case setting is a hospital (medical industry) where the access to medical records is denied, putting numerous lives at risk. As the hackers try to extort money, the case raises ethical and legal questions and forces participants to make tough decisions. Coutu (2007) raises ethical questions about the growing issue of lack of privacy in the networked world. The case addresses whether the information found on Internet about a person can become a burden in advancing the person’s careers. Ethical and privacy questions related to confidentiality of data and data reuse in business settings are also raised (Davenport & Harris, 2007; Fusaro, 2004; Schenberger & Mark, 2001). Davenport and Harris (2007) present a case that deals with the issue of data reuse. It is a common practice for businesses to share customer data with the businesses’ affiliates. The case in question asks at what stage is the sharing of information detrimental to customers? In a similar vein, Fusaro’s (2004) case asks at what stage do the data collected for customization cross the boundary and become invasion of privacy? DoubleClick’s profiling issues and breach of privacy are also well known (Schenberger & Mark, 2001). Complaints filed with the Federal Trade Commission had a severe impact on the shares of DoubleClick and led to the development of privacy policies (Schenberger & Mark, 2001). 86 Ayyagari & Tyks As this review points out, security case studies generally focus on business settings even though educational institutions experience a fair share of security incidents. We address this gap by first presenting a case study of a security breach at a university. We conclude by providing discussion points and the lessons learned from this case study. Disaster at a University – A Case Study Turn Key University (TKU) is a medium sized public university located in Idaho. The institution is situated on a beautiful 25 acre campus, just north of a major city. The University consists of over 6,000 students mostly from the surrounding region. The institution is a liberal arts college that offers over 30 undergraduate majors and a dozen graduate degrees. The school has a reputation for producing quality graduates for the surrounding community. The University is a major employer in the area, providing jobs for over 900 employees. Organization Hierarchy The institution was organized as a typical university bureaucracy, with the President’s office overseeing the Academic Affairs, Administrative Support Services, Human Resources, Finance, and Information Technology divisions as shown in Figure 1. The IT, Finance, and Administrative Support divisions are the primary focus of this case. President’s Office Academic Affairs Administrative Support services Finance Human Resources Information Technology Figure 1: TKU’s Organizational Hierarchy As shown in Figure 2, the Information Technology division consisted of six departments -- Institutional Projects, Media Services, Teaching Support, Computing Systems, Web Services, and Network & Telecom. Each of these departments was managed by a Director who reported to the Chief Information Officer (CIO). The Information Technology Division managed all aspects of computing on the University campus. The IT division employed over 70 permanent members and several temporary/student employees. The IT division required a large server farm to manage a transaction management system and other systems. TKU centralized all server functions in the Computing Systems department. 87 Information Security Disaster CIO Director Institutional Projects Director Computing Systems Director Media Services Director Web Services Director Teaching Support Director Network & Telecom. Figure 2: IT Division Hierarchy Administrative Support Services supported the ancillary services offered by the college. Among other things, this division managed relationships between the on-campus and off-campus vendors. On-campus vendors include the post office, GoodFood (the student meal plan provider), CollegeBooks (the bookstore operator), and FastSnack (the snack machine provider). The snack machines were an important part of students’ life as many students relied on late night RedBull® runs to make it through a last minute cram session. Off-campus vendors include restaurants, tanning parlors, and gas stations. Compared to the IT division, Administrative Support Services was relatively small, with approximately one-fifth the numbers of personnel in the IT division. The Finance Division was responsible for managing and reporting the financial state of the University. The division was made up of five departments: Financial Affairs, the Budget Office, Accounts Receivable, Accounts Payable, and Student Services. All financial information reporting was overseen by the Financial Affairs department. Overall, the Finance division employed 30 permanent employees and several part-time members on a need basis. System Description Since 2000, TKU used a transaction management system for student meal plans. There were three different meal plan tiers: a lower volume plan that was aimed towards commuters, a middle volume plan that was targeted for full time students who leave on the weekends, and a high volume plan that was designed for students who eat all meals on campus. Out of the three plans, the middle volume plan was the most popular among students and responsible for the majority share of the transactions. In addition to the meal plans, the transaction management system handled virtual dollars. Virtual dollars can be thought of as a prepaid credit card. At the beginning of the semester students were given a balance based on their meal plan, and students drew down the balance by purchasing items from vendors. Students and parents were also able to add additional funds on the card through an online portal. Students paid for items using virtual dollars at a variety of vendors – they spent it on books from the bookstore, stamps from the post office, drinks from the snack ma- 88 Ayyagari & Tyks chines, and on food from neighborhood restaurants. Virtual dollars were a hit with students as they enjoyed having the freedom and convenience to pick what they wanted, when they wanted. The transaction management system was more than a way for students to purchase food; it was also a profit center for the college. From a fiscal perspective, the system was able to generate annual profits of $600,000 for TKU. Most of the revenues were from commissions on sales to vendors. Due to corporate cultural issues (as discussed below), the control of the system spanned across the IT, Administrative Support Services, and Finance divisions, although none of the divisions received commissions. All the money generated from the system went into a central fund managed by the President’s Office. History of the System: Reflection of Corporate Culture The Transaction Management System (TMS) had been in place for over ten years at the writing of this case and within that time frame it had changed hands multiple times. Initially the system was handled by the Computing Systems department in the Information Technology Division. The typical system administrator learned about the system on-the-job in an informal fashion, and there was a lack of process or steps that could be reproduced when system administrators changed. Further, when the system was implemented, security was an afterthought and security responsibilities played a minor role in system administrators’ job duties. As a result, the current state of the system was that (1) there was a lack of formal process in managing the system and (2) the system was never secured. At the time of writing, the system was managed by two administrators – Gary and Tom from the Computing Systems department. They had been in their roles for a little over a year. Although the TMS system depended on multiple divisions (IT, Finance, etc.,) for effective operation, the incentives in place were conducive to reinforcing the functional boundaries among various divisions (see Figure 1), thus resulting in friction among divisions. As the TMS grew in stature, the logical solution to reduce the political tensions among divisions was to split the system responsibilities among the divisions. In this arrangement, IT continued to manage the servers with Gary as the primary administrator and Tom as the backup. The Finance division took over the administration and user access portion of the system. The responsibilities for system administrator fell on Don who had some technical background and was seen as a ‘tech geek’ in the Finance division. At the time of this case study, Don had been in the system administrator role for three months. When Don inherited the system, he received no formal system administration or security training and found that there were no formal policies or business rules in place. As he learned the system, he realized it housed a large amount of personally identifiable information (PII). There were student social security numbers (which acted as a students’ primary ID in the university system), addresses, phone numbers, birthdates and meal plan information. The Security Structure: Technical Safeguards The security structure was handled in two different ways. The first was by ensuring only authorized people had access to the system. The second was by viewing events in the log files. The system was set up in a typical hierarchical structure, comparable to Windows Active Directory. There were user accounts that branched into user groups. People could access the system by logging in with a username and password, similar to how a person would access their home computer. When a user needed an account, the system administrator would assign a username and password. Once a user had a username, the system administrator placed the user in the appropriate user group, which determined what functions the user could perform. The administrator group had full permissions and consequently had free reign of the system. Among other things, the administrator could run reports, change meal plan settings, upload data and export data from the system. 89 Information Security Disaster The next method of managing system security was through the log files. The transaction management system created system logs whenever an event occurred. This feature was very useful for showing what happened within a system. The logging feature showed the time, the user group, and the event that occurred. While the logs were useful, the primary drawback was that they only showed what group created an event. As a result, events could only be seen at the group level. This means if a user logged into the system and made a change and was a member of the administrator group, the log would only show that someone in that group made a change. It didn’t show which user made the change. The Issue: Data Breach Early one morning, Don was ushered into a closed door meeting with the Chief Finance Officer, the CIO, and an external security auditor he hadn’t met before. In the meeting Don learned that large amount of data, including the PII, was exported from the system. The previous day Gary was going through the logs to see if the patch he applied worked correctly, and he noticed that someone in the administrator group had exported a large amount of data at an odd time. Gary reasoned that no one should be accessing the system at 2am, and he was concerned because a large amount of data was exported. After bringing up the issue to management, it was decided that the Finance division would investigate the issue. Therefore, the responsibility to figure out exactly what happened fell on Don. He was asked to work with an auditor to find out exactly what happened. Don left the meeting feeling overwhelmed and disconcerted; he knew nothing about security practices and he wasn’t happy about working with the auditor. He had recently inherited the system and didn’t know much about it. He did know that he had to find the source of the leak before more student information was lost and he knew his job might be on the line. The Investigation: Lax Security Policies and Culture The auditor decided to interview the users of each business unit. At a basic level, he wanted to figure out if the leak was an internal job or if TKU had fallen victim to a hacker. So, he wanted to see the different entry points that a potential hacker could get access to the system. Further, the auditor felt it necessary to check the user account structure, the business rules, and department norms. By doing this, the auditor felt confident that he could determine which user in the administrator group was responsible for the data leak, if it was an internal job. Throughout the investigation, Don was going to support the auditor and would provide the required information. The auditor and Don started the audit process by going through the system. They checked the user accounts and found multiple points where a hacker could have entered the system. They found over 50 orphan accounts, which are accounts that had been set up but never used. When an account is set up, the policy is for the system administrator to provide the same generic password. Once a user logs into the system, they are prompted to enter a new password. Since none of these accounts were used, all of the accounts had the same password. A hacker could have easily cracked the generic password and gotten access to the system. Another area of concern was with password complexity. The system didn’t require users to have strong passwords. Passwords could be as short as three characters long and didn’t need to include numbers or special characters. The passwords could be kept forever and most had never been changed. With the current sophisticated password cracking programs available on the Internet, hackers could break into the system in seconds. This seemed very likely as figuring out the system usernames was very easy. The usernames were based on the name of the user. The first letter of the username was the first letter of the person’s first name. The last part of the username was the person’s last name. For example, Gary Tolman’s username was gtolman. This type of username assignment is very common, but it can also pose a threat. Each employee’s name was listed on the TKU website, so a hacker could easily find a username. 90 Ayyagari & Tyks Lastly, the system was accessed by a variety of users. They were spread out between Information Technology, Finance, and the Administrative Support Divisions, so finding the exact users would be difficult. Anyone in these divisions could be the source of the leak. Don and the auditor didn’t know how they were going to trace the culprit, but they knew they had a daunting task. They started off by interviewing people in the three divisions. The Administrative Support Services division used the transaction system to run reports, so the users only had permissions to run reports. Don and the auditor found that in addition to the approved users, more people accessed the system. Employees routinely gave out their login information to student workers and temporary employees to run reports when they were busy or on vacation. The employees shared this login information on Post-it® notes, over the phone, and in email. The department did not have rules explaining proper procedures, so employees thought these practices were acceptable and the norm. Next, Don and the auditor interviewed people in the IT Division. They focused on the Computing Systems department, which handles the technical end of the transaction management system. This includes duties such as managing the server, setting up off-campus merchants, maintaining oncampus connections, and troubleshooting networking issues. The transaction management system from an IT perspective is a server with a simple front end that users log into and a database that holds the information. Don and the auditor found that there were no formalized policies or procedures detailing how to complete tasks. There were no business rules and the department lacked consistency in its approach to managing the system. In this department, three administrators had full administrative rights, so they had full access to the system, allowing them to add user permissions or initiate data exports. During the interview, Don and the auditor also realized that in the past when IT handled information security employees routinely gave out initial passwords in email or on the phone. There was only one clear written policy and that was broken routinely. The policy stipulated the Finance division was to extract the required data to run reports from the system. However, the IT division continued to extract data for the majority of users. People preferred IT to extract the data because they were quicker than Finance. Further, the auditor was informed that there was a major upgrade to the campus infrastructure recently, and during that time outside contractors were on-site as technical advisors. The contractors were supposed to have given limited access, but by this point, the auditor was not convinced if this exactly happened. The following day, Don and the auditor looked at the Finance division. The Finance division handled the system administration and the access permissions for the system. The department also oversaw the functional components, such as crediting accounts if a student was charged incorrectly for an item. The system was also used to run business intelligence reports. Don was the primary administrator for the system, so he had complete access to it. He was able to perform functions such as setting up user accounts and exporting data. It was his responsibility to ensure that correct people had access to the system. At this point, Don took a back seat and the auditor interviewed him. The auditor realized that Don didn’t have much experience managing the system. Further, he also gave out passwords to users through email or on the phone. The auditor also found that Don didn’t require users to have strong passwords. Next, the auditor interviewed the accountants that used the system. The accountants had only limited access to the system. They could post transactions and transfer funds, but nothing to the extent of exporting data. The Outcome: Victim of Social Engineering Throughout the process, the auditor found countless examples of lax information security throughout the organization. There was a lack of a coordinated security policy, and the policies in place were not being followed. While reviewing the notes, the auditor noticed that a contractor requested the TMS server address over the phone. Further follow up revealed that a system ad- 91 Information Security Disaster ministrator gave out the server address to a contractor because the contractors were in the middle of upgrading servers. The administrator also mentioned that the contractor requested the password, but the administrator didn’t feel comfortable sharing the password on the phone and asked the contractor to stop by the office – but the contractor was a no show. From the description of the events, the auditor felt it was a social engineering attempt. Social engineering is when a hacker attempts to gain access to sensitive information by tricking a person into giving it to them. The immediate recommendation of the auditor was to focus on the contractor’s activity in the organization. Over the next few weeks the story unfolded and all the pieces of the puzzle were put together. It was eventually proven that the contractor stole the information. The contractor was hired to oversee the upgrade of servers on the storage network. While doing this, she learned about the transaction management system. She knew PII could be sold on the black market and thought the lax security at TKU would enable her to get away with stealing data without any repercussions. Her only obstacle was access. Since she only had access to the storage network, she needed a way to get access to the transaction management server. That’s when she called the system administrator and got the IP address and tried to get his login credentials. Once she got the IP address, she was able to utilize the free tools available on the Internet to scan the system and get the username and password with administrative access. It took her only a matter of minutes to get this information. The password was only three characters long and didn’t use any numbers or special characters. With her new administrative permissions, she was able to export the PII. The Aftermath TKU was very lucky with the outcome of the data breach. Only five hundred students had their information compromised. While any loss of PII is unfortunate, high profile data breaches, such as the ones at TJX, show how losing large amounts of data can be very costly to an institution. Like many businesses, the University attempted to keep the data breach quiet, but the breach information was eventually released. The fear of student backlash and the need to be compliant with privacy breach laws forced the university to inform the campus community of the breach. Students were initially very angry and felt as though they could not trust the university with their private data. To help improve student morale, the president offered reduced tuition for a semester and a year of paid credit monitoring service to victims of data breach. The University’s generous response helped to calm the protests, but it came at a price. TKU estimated that the tangible costs associated with the breach amounted to over $600,000 dollars. However, TKU will never know how the breach affected the university’s reputation. Discussion This case is presented in an educational setting and raises numerous issues that deserve attention. People, Process and Technology are identified as essential pillars of good security practices (Merkow & Breithaupt, 2005). This case can be analyzed from this perspective. The main lessons learned from this case are presented in Table 1. The table highlights the security themes supported by literature and the suggested improvements. One of the main recurring themes in the case is that of lax security policies. Strong leadership is needed to develop a security program that changes the security culture in the organization so that security behaviors become second nature to employees (Thomson, von Solms, & Louw, 2006). Although developing a security program can be challenging, the biggest challenge faced by management is justifying the cost. However, this shouldn’t act as a deterrent as, with proper planning, the program can be developed on a shoestring budget (Sridhar & Bhasker, 2003). TKU can significantly improve the security culture and strengthen its security efforts by appointing a chief security officer (Lowendahl, Zastrocky, & Harris,2006). Having a dedicated figurehead for secu- 92 Ayyagari & Tyks rity can also alleviate some of the tensions between departments with respect to dealing with security incidents. Throughout this process, management should realize that ‘complete security’ is a myth and the university needs to be constantly prepared (Austin & Darby, 2003). Table 1: Lessons learned Security Theme Top Management Support Access Control Practices Supported from Literature Practices Supported from Literature Top management support is necessary to dedicate resources, create policies, and establish culture & norms (Lowendahl et al., 2006; Panko, 2009; Thomson et al., 2006). The lack of security figurehead is a major drawback. The university should consider appointing a chief security officer. Strong access control (password) policies need to be implemented (Merkow & Breithaupt, 2005; Scarfone & Souppaya, 2009). Access should be based on the principle of least privilege to accomplish an individual’s task. Access control policies need to be formalized. Constant communication is needed to change the security culture. The cases of sharing and giving passwords over the phone, writing them down are clear violations of access control best practices. Since policies are good only to the degree they are enforced, violations should result in some disciplinary action. This would also enhance the security culture. Training / Awareness As security landscape changes constantly, so does the need to retool employees with latest training (Hentea, 2005; Wilson & Hash, 2003). For example, training programs that are few years old would not have included the aspect of social networking sites. The employees need to be constantly reminded that they are an integral part of security. The training program needs to be implemented and constantly reviewed to keep up with the changes. TKU should invest significant resources in raising awareness among its users. In a study of security practices in university settings, Caruso (2003) reports that the greatest barriers to security are availability of resources and awareness. It is often the case that to achieve effective security, focus should be on humans, not technology itself (Caruso, 2003). Hentea et al. (2006) report that “User awareness and education are the most critical elements because many successful security intrusions come from simple variations of the basics: social engineering and user complacency” (page 228). Therefore, TKU should also ensure that proper training is provided for all employees so that they become aware of security threats. Ideally, this training program should be recurrent, as new threats arise continuously (Medlin & Romaniello, 2007). It is recommended that employ- 93 Information Security Disaster ees take security training and, then, keep up-to-date with a refresher course once a year. Further, employees responsible for sensitive information need to be properly trained with respect to regulatory compliance. For example, proper training in social engineering aspects could have provided the employees with the tools needed to identify these type of attacks and could have probably avoided the TKU’s breach. As Mitnick (2003) argues, the weakest link in the security chain is not technological, but it is the human element. He provides simple examples about how even with sound technical defenses, it is still possible for an attacker to gain upper hand by using social engineering. Such training could bolster the work force and can make the employees cognizant and cautious in their approach to security. Another place in which the process and technology need to improve is with respect to access control. Currently, TKU has a very weak password policy and it should be improved. However, the password issues faced by TKU are not uncommon. In a study of health care workers, it was found that passwords used to protect sensitive patient information had significant problems (Medlin & Romaniello, 2007). For example, it is reported that some users had same or similar passwords as their usernames. Another study of actual e-commerce passwords revealed that one-third of users used very weak passwords and the time it took to crack these passwords was less than a minute (Cazier & Medlin, 2006). A recent study studying users’ password practices found that users don’t use strong passwords (Barra, McLeod, Savage, & Simkin, 2010). A typical strong password consists of alpha numeric characters (upper and lowercase), symbols, and is at least 8 characters long. Also, studies have revealed that individuals (especially in university settings) are willing to give their own and their friends’ passwords for some token gifts (Smith, 2004). Given the problems with remembering passwords and the simplicity of passwords, it is proposed that users develop and utilize passphrases to improve password security (Keith, Shao, & Steinbart, 2009). Users should also be discouraged from sharing or mailing passwords and principles of ‘least privilege’ required to perform a job should be adopted (Merkow &Breithaupt , 2005). Further, keeping up with industry standards, TKU should consider moving away from using social security numbers for identification. Conclusion This paper begins by discussing the importance of using case studies as a pedagogical approach. It is noted that the majority of data breaches since 2005 occur in educational institutions. Therefore, it is important to address this segment so that appropriate protections are in place. To this end, Gartner research recommends the use of case studies in educational settings to improve the security (Lowendahl et al., 2006). Accordingly, the case presented here deals with the issue of data breach at a university. The events leading up to the breach and the subsequent analysis are presented. In conclusion, the case demonstrates the security problems and proposes possible solutions in an educational setting. References Auster, E. R., & Wylie, K. K. (2006). Creating active learning in the classroom: A Systematic Approach. Journal of Management Education, 30(3), 333-353. Austin, R. D., & Darby, C. A. R. (2003). The myth of secure computing. Harvard Business Review, June, 120-126. Barra, R., McLeod, A., Savage, A., & Simkin, M.G. (2010). Passwords: Do user preferences and website protocols differ from theory? Journal of Information Privacy and Security, 6(4), 50-69. Bok, D. (1986). Higher learning. Cambridge: Harvard Business Press. Bradford, B. M., & Peck, M. W. (1997). Achieving AECC outcomes through the seven principles for good practice in undergraduate education. Journal of Education for Business, 72, 364-368. 94 Ayyagari & Tyks Caruso, J. B. (2003). Information technology security: Governance, strategy, and practice in higher education. ECAR, 1-7. Cazier, J. A., & Medlin, B. D. (2006). How secure is your password? An analysis of e-commerce passwords and their crack time. Journal of Information Systems Security, 2(3), 69-82. Coutu, D. (2007). We googled you. Harvard Business Review, 2007, 37-42. Davenport, T. H., & Harris, J. G. (2007). The dark side of customer analytics. Harvard Business Review, May, 37–41. Eisenmann, C. (2009). When hackers turn to blackmail. Harvard Business Review, October, 39–42. Fusaro, R. A. (2004). None of our business? Harvard Business Review, December, 33–38. Goorha, P., & Mohan, V. (2009). Understanding learning preferences in the business school curriculum. Journal of Education for Business, 85(3), 145-152. Gregg, M. (2008). Build your own security lab: A field guide to network testing. Indianapolis: Wiley. Haggerty, N. R. D., & Chandrasekhar, R. (2008). Security breach at TJX. Ivey Publishing, 9B08E003. Hentea, M. (2005). A perspective on achieving information security awareness. Issues in Informing Science and Information Technology, 2, 169-178. Hentea, M., Dhillon, H.S., & Dhillon M. (2006). Towards changes in information security education. Journal of Information Technology Education, 5, 221-233. Retrieved from http://www.jite.org/documents/Vol5/v5p221-233Hentea148.pdf Keith, M., Shao, B., & Steinbart, P. (2009). A behavioral analysis of passphrase design and effectiveness. Journal of the Association for Information Systems, 10(2), 63-89. Kim, Y., Hsu, J., & Stern, M. (2006). An update on the IS/IT Skills gap. Journal of Information Systems Education, 17(4), 395-402. Kroenke, D. M. (2012). Using MIS. New Jersey: Prentice Hall. Laudon, K., & Laudon, J. (2010). Management information systems. New Jersey: Prentice Hall. Lowendahl, J-M., Zastrocky, M., & Harris, M. (2006). Best practices for justifying and allocating highereducation security resources. Gartner Research, G00137454. McNulty, E. (2007). Boss, I think someone stole our customer data. Harvard Business Review, September, 37-42. Medlin, B. D. & Romaniello, A. (2007). An investigative study: Health care workers as security threat suppliers. Journal of Information Privacy and Security, 3(1), 30-46. Merkow, M., & Breithaupt, J. (2005). Information security: Principles and practices. New Jersey: Prentice Hall. Meyers, C., & Jones, T. (1993). Promoting active learning: Strategies for the college classroom. San Francisco: Jossey-Bass. Mitchell, R. C. (2004). Combining cases and computer simulations in strategic management courses. Journal of Education for Business, 79(4), 198-204. Mitnick, K. D. (2003). Are you the weak link? Harvard Business Review, April, 18–20. Panko, R. P. (2009). Corporate computer and network security. New Jersey: Prentice Hall. Pariseau, S. E., & Kezim, B. (2007). The effect of using case studies in business statistics. Journal of Education for Business, 83(1), 27-31. Privacy Rights Clearinghouse. (2011). http://www.privacyrights.org Retrieved August 18, 2011. Qayoumi, M. H., & Woody, C. (2005). Addressing information security risk. EDUCAUSE Quarterly, 28(4), 7-11. 95 Information Security Disaster Richards, L. G., Gorman, M., Scherer, W. T., & Landel, R. D. (1995). Promoting active learning with cases and instructional modules. Journal of Engineering Education, 84(4), 375-381. Scarfone, K., & Souppaya, M. (2009). Guide to enterprise password management. NIST Special Publication 800-118. Schenberger, S., & Mark, K. (2001). DoubleClick Inc.: Gathering customer intelligence. Ivey Publishing, 9B01E005. Shapiro, B. P. (1984). An introduction to cases. Harvard Business School Note, 9-584-097. Smith, S. W. (2004). Probing end-user IT security practices – through homework. Educause Quarterly, 27(4), 68-71. Sridhar, V., & Bhasker, B. (2003). Managing information security on a shoestring budget. Annals of Cases on Information Technology, 5, 151-167. Thomson, K-L., von Solms, R., & Louw, L. (2006). Cultivating an organizational information security culture. Computer Fraud & Security, 10, 7-11. Wilson, M., & Hash, J. (2003). Building an information technology security awareness and training program. NIST Special Publication 800-50. Wingfield, S. S., & Black, G. S. (2005). Active versus passive course designs: The impact on student outcomes. Journal of Education for Business, 81(2), 119-123. Biographies Dr. Ramakrishna Ayyagari is an Assistant Professor in Information Systems at the University of Massachusetts at Boston. He earned his doctorate in management from Clemson University. His work has been published or forthcoming in outlets such as MIS Quarterly, European Journal of Information Systems, Journal of the AIS, Decision Sciences, and the proceedings of various conferences. Jonathan Tyks has been employed in the Information Technology field for over ten years. He holds a bachelor’s degree in Management Information Systems from Bridgewater State University and an MBA from The University of Massachusetts at Boston. He currently resides in Boston, MA. 96 Running Head: Project #5: Implementation Plan Project #5: Implementation Plan Great Student September 27, 2018 Project #5: Implementation Plan I. Introduction After suffering a large-scale data breech in which the personally identifiable information (PII) including sensitive financial information of 500 students was compromised, Turn Key University (TKU) commissioned an external auditor to conduct an investigation in concert with the Transaction Management System (TMS) system administrator (SYSADMIN). The breach cost TKU $600,000 to address, which represents 100% of the annual profits generated by the system for the school and does not include the incalculable loss of prestige as the event caused many students to view the school’s commitment to securing them and their information negatively. The investigation traced the source of the breach to a contractor that had been hired oversee upgrades to the school’s storage network servers that successfully employed social engineering in order to gain access to the TMS. However, it is more important to determine the conditions that led up to this event and identify any people, process, or technology gaps that contributed to it. Unfortunately, the investigation identified several serious gaps in all three areas combined with dysfunctional information technology management and an extremely lax security environment (Ayyagari & Tyks, 2012). The purpose of this document is to recommend a security plan to address the gaps identified in the investigation and prevent or mitigate future risk posed by vulnerabilities in the school’s cybersecurity program. It is important to note that cybersecurity is an ongoing process and will require commitment from all levels of leadership within the school from the president down to individual employees. Furthermore, improving TKU’s security and ensuring the confidentiality, integrity, and availability of its’ networks and data will require an investment of time and resources, although steps will be taken to ensure that these costs will be closely managed. Lastly, this plan will recommend drastic changes to the school’s culture among the staff and 2 Project #5: Implementation Plan faculty, which may be met with resistance. It is vital that leadership maintain clear, open lines of communication throughout the entire process in order to avoid potential conflict or disruptions caused by these changes. II. Goals and Objectives In order to achieve the desired end state, it is vital that organizations and projects employ a clear set of goals. Goals are broad and provide an overarching context for what the business or project seeks to achieve. Business goals must be developed first so that project goals can be correctly aligned. Goals are then supported by objectives, which are more specific and describe the products or tangibles that are needed to achieve said goals (Mochal, 2017). Business goals are more long-term and generally look three to five years in the future. These goals should articulate TKU’s mission statement regarding cybersecurity. For example, “ensuring the confidentiality, integrity, and availability of Turn Key University’s networks and information” is a cybersecurity business goal. Once long-term business goals are determined, short-term objectives to get to the goal must be developed. These objectives should be SMART, which stands for specific, measurable, action-oriented, realistic, and time-specific. For example, “become ISO 27001-compliant by 2020” could be an objective that supports TKU’s cybersecurity goals (Vanden Bos, 2010). This project will contribute to TKU’s cybersecurity business goals by addressing the vulnerabilities in the Transaction Management System itself. The overall goal of the project is to ensure the system’s confidentiality, integrity, and availability while protecting sensitive financial information and PII belonging to TKU’s students. As with business objectives, project objectives must be SMART and provide a path to achieve the project’s stated goals (Mochal, 3 Project #5: Implementation Plan 2017). An example of one of this project’s objectives is “institute a strong password policy for TMS that requires 10 characters of which one must be a number and one must be a special character by the end of this fiscal year.” A. Business Goals and Objectives Many of the issues and vulnerabilities identified during the investigation are related to TKU’s organizational structure and culture. For starters, Information Technology (IT) is one division out of five and is overseen by the Chief Information Officer who reports to the University President. The IT division is comprised of six departments that manage all aspects of on-campus computing. However, there is no person or department formally tasked with managing and implementing TKU’s information security program (Ayyagari & Tyks, 2012). In order to address this structural issue in people and process, the following recommendations are made: Goal: Improve TKU’s information security program and centralize its’ management. Objectives: Create an Information Security Department overseen by a Chief Information Security Officer (CISO) within the IT Division within 12 months. Employ a qualified CISO to oversee the creation and management of the Information Security Department within 6 months. Staff the Information Security Department with at least three cybersecurity experts within 6 months. The investigation also found that there is no formal security policy, and what policies are in place are not followed with no consequences for failure to do so (Ayyagari & Tyks, 2012). There are several information security frameworks available to guide the CISO in the development and implementation of a security program and the supporting policies. Some policies that should be adopted include acceptable use policy, password policy, social media 4 Project #5: Implementation Plan policy, and a clean desk policy for the entirety of TKU’s computer networks (CSO Staff, 2016). In order to address this gap in process, the following recommendations are made: Goal: Improve TKU’s security program and policies. Objectives: New Information Security staff conduct a complete review and overhaul of TKU’s information security program and policies within one year of the Information Security Department becoming fully operational. CISO and staff develop a security program and submit to the president for approval within one year of department creation. Policies will be developed by security personnel once program is approved. All division heads review and offer comments on each policy within ten business days of receipt. CISO approve or disapprove inputs within five business days after comment period is closed. CISO submit each policy to the President for approval once complete. University president approve or return to CISO for revision within ten business days of receipt of each policy. Policies requiring modification are due back to the president for final approval within five business days. Updated policies will contain punitive measures for compliance failure. The root cause of this breach was a successful social engineering attempt to gain sensitive access information to the TMS. The perpetrator leveraged her legitimate role overseeing an upgrade to the storage servers to obtain the TMS’ internet protocol (IP) address from the SYSADMIN. Although she was unable to obtain his login credentials, she was able to utilize free password cracking tools available on the open internet. This attempt was successful because it is highly probable that the SYSADMIN did not recognize that he was being socially engineered due to a lack of awareness (Ayyagari & Tyks, 2012). “Users are the largest audience in any organization and are the single most important group of people who can help to reduce unintentional errors 5 Project #5: Implementation Plan and IT vulnerabilities” (Wilson & Hash, 2003). Therefore, to address this gap in people and process, the following recommendations are made: Goal: Improve cybersecurity awareness among TKU employees, faculty, and staff. Objectives: Information Security Department personnel utilize NIST SP 800-50 to develop and implement a cybersecurity training program within one year of the department’s creation. Institute mandatory training for all newly hired personnel to be delivered at orientation within one year of the security department’s creation. Institute annual refresher training for all staff and faculty within one year of the security department’s creation. The final business goal pertains to access control for all of TKU’s networks including the TMS. In the course of his investigation, the auditor discovered that login credentials and passwords are freely shared, do not meet recommended strength requirements, and are not required to be changed beyond the initial login. Furthermore, all accounts are created with the same, weak password that must be changed upon the first login. However, if an account is created and left “orphaned,” where they are never logged in to as happened in more than 50 instances on the TMS, then attackers can easily gain access without being detected. To address this gap in process, the following recommendations are made: Goal: Improve TKU’s access control and password procedures. Objectives: Immediately implement a password policy and adjust network policy settings to force users to use complex passwords containing at least 8 characters with one number and one symbol. Immediately implement a password policy and adjust network policy settings to require users to change their passwords periodically (every 180 days, etc.). Immediately implement an administrative password policy that forbids users from sharing passwords and leaving them in 6 Project #5: Implementation Plan the open. Implement disciplinary processes for any violations. Explore issuing log in “tokens” to all faculty and staff accessing TKU’s corporate network that require unique credentials. B. Project Goals and Objectives While many of the business goals and objectives outlined above will address vulnerabilities in all of TKU’s networks, including the TMS, this project is intended to specifically rectify the weaknesses within the management of the TMS and the systems itself. To that end, the first goal of this project is to codify system administration responsibilities for the system and streamline the entities that have management roles in the system. To address these people and process gaps, the following recommendations are made: Goal: Provide a designated, qualified SYSADMIN and alternate for the TMS and place responsibility for the system within a single entity. Objectives: Immediately hire a qualified SYSADMIN and alternate and place them within the Computing Systems Department of the Information Technology Division. Place all administrative controls for the TMS within the Computing Systems Department. Ensure that the primary and alternate SYSADMINs are appropriately trained and possess the necessary certifications (NETWORK+, SECURITY+, Microsoft, etc.). Designate the SYSADMINs in writing, and adjust network settings to provide only them with privileged access. Remove any privileged accesses from non-SYSADMIN personnel and adjust their roles accordingly. Because the TMS processes financial transactions using credit cards and the internet, it is bound by electronic banking laws and industry standards. The Payment Card Industry Data Security Standards (PCI-DSS) are a set of standards developed by the biggest credit card companies and required for any business that process payments using their cards. Failure to comply with these 7 Project #5: Implementation Plan standards can result in the loss of the ability to process these cards which include Visa, Mastercard, and American Express. Furthermore, PCI-DSS compliance will ensure that TKU is in compliance with applicable laws and other regulations (PCI Security Standards Council, 2018). In order to address these gaps in people, process, and technology, the following recommendations are made: Goal: Make TKU’s TMS PCI-DSS-compliant. Objectives: Immediately hire a PCI-qualified assessor to conduct an assessment of the TMS for PCI-compliance. Based upon these findings, implement all recommendations within 180 days of the assessor’s report. Once the TMS is PCI-compliant, transfer compliance responsibilities to the SYSADMINs and newly created security department once operational. Conduct annual compliance audits internally, or by employing an outside consultant. Finally, the attacker’s data theft was logged in the system’s event logs, but there was no mechanism in place to recognize or respond to an attack or breach. TKU’s current TMS architecture does not employ an intrusion detection system (IDS) that would notify network administrators of an attack and log the events for later forensic analysis. Furthermore, TKU does not have an existing process in place to notify appropriate personnel in the event of an attack, to respond to an attack, or to recover from an attack. In order to address these gaps in process and technology, the following recommendations are made: Goal: Deploy an IDS on the TMS and improve TKU’s incident response strategy. Objectives: Immediately procure and install a robust IDS on the TMS. Assign monitoring responsibilities to the SYADMINs who will report to the CISO once their department is operational. Once the SYADMINs and security personnel are in place, begin annual intrusion 8 Project #5: Implementation Plan and response testing. CISO and staff will develop and implement an incident response program, which will be approved by the CIO, within 24 months of the department becoming operational. III. Scope In order to prevent this project from expanding beyond the desired end state, establish deliverables and timelines, and assign tasks its’ scope must be clearly stated (Rouse, 2018). As indicated previously, this project is to address only the people, process, and technology gaps within the TMS as discovered by the data breach investigation. Beyond this report, deliverables and responsibilities are defined below. Scope Definition The Chief Information Officer is assigned as the project lead, although TKU’s president will approve all hiring, policy, and procurement recommendations produced at its’ end. Upon delivery of this report, the CIO will have 90 days to compile an internal, comprehensive report with detailed recommendations and a plan of actions and milestones (POA&M). Suggested milestones are contained later in this document, although the CIO and his staff may offer additions or deletions as deemed appropriate. This report will also contain a recommended network architecture for the TMS which the CIO may or may not endorse for approval by the president. Items Beyond Scope While the business goals and objectives offered recommendations that are applicable to the TMS and TKU’s other networks, the administration of non-TMS networks and the day-to-day 9 Project #5: Implementation Plan specifics of the TMS program are not included. The following items are beyond the scope of this project: • Non-TMS network administration and security. • Non-TMS network architecture. • Developing specific policies for TKU’s networks. • Implementing any security framework or strategy on any of TKU’s networks. • Recommending personnel or assisting in hiring decisions for recommended positions. • Recommending disciplinary action for any employee found in violation of existing policies. • Recommending specific hardware or software products. • Developing or providing training for selected TMS SYSADMINs. • Developing or implementing specific meal plans. • Setting item costs within the TMS. • Recommending food and drink vendors serviced by the TMS. IV. Projected Expenses Improving the cybersecurity posture of the TMS will require some investment of time and resources. Recommendations regarding policy and organizational structure may be implemented with no outlay of resources beyond the time involved to develop and implement them. Additional staffing and technological changes will require a monetary expenditure both initially and over time. A detailed cost-benefit analysis must be performed prior to approving any additional financial outlay. It is important to note that personnel are generally the greatest expense of most organizations. 10 Project #5: Implementation Plan System Development Lifecycle/Schedule Although TKU’s network infrastructure, including the TMS, was recently upgraded it is recommended that the IT division perform an assessment of the TMS architecture utilizing the steps of the system development lifecycle (SDLC). It is essential that an approach incorporating risk management be used and that security is integrated at every phase of the SDLC. TKU should implement a documented, repeatable SDLC program in order to ensure that security concerns are addressed on the TMS hardware and software as well as to inform future purchasing and retirement decisions (Kissel, et al., 2008). The average SDLC consists of five phases: initiation, development/acquisition, implementation/assessment, operations/maintenance, and disposal. Within each phase there are security tasks to be completed in order to ensure that security has been properly incorporated (Kissel, et al., 2008). As TKU has an existing TMS architecture, they are located in the operations/maintenance phase of the cycle. The main security activities within this phase include conducting an operational readiness review, managing the system/network configuration, instituting assured operations and continuous monitoring of security controls, and reauthorizations as required (Kissel, et al., 2008). NIST SP 800-64 Rev. 2, included in the references, lists specific responsibilities for all stakeholders within the SDLC and specific security measures to be implemented at each phase. Milestones Within the operations/maintenance phase are four control gates or milestones. The first is a readiness review of the architecture, which has been preliminarily satisfied by this report although a more in-depth, internal review within six months is recommended. As gaps have 11 Project #5: Implementation Plan been identified, the next step of reviewing proposed changes should be executed within 30 days of the review’s completion. Once changes have been approved, the CIO will submit a POA&M for execution to the president within 45 days of approval. Finally, it should be determined if the approved changes have satisfied regulatory and legal accreditation requirements. Of note, an accreditation review should be completed every three years or after any network change (Kissel, et al., 2008). V. Assumptions The recommendations offered in this document are predicated on events and decisions that have yet to be made. As such, their outcome has been assumed. These assumptions have guided the development of this document, and any final decisions may result in deviation from the stated desired outcome contained therein. All final decisions are the purview of the president and the CIO. Project Assumptions For this project, the following assumptions were made. • The average CISO salary in the United States was $204,000 in 2016. Idaho’s lower cost of living will likely allow TKU to offer prospective candidates less money, although certifications and experience can drive up wages (Morgan, 2016). • Cybersecurity analyst salaries range from $51,000 to $121,000 with a median of $75,500 depending on experience and certifications (PayScale, 2018). Idaho’s lower cost of living should allow them to make an offer at the lower end of the spectrum. • Responsibility for TMS administration will be placed under sole control of the IT Division and the CIO. 12 Project #5: Implementation Plan • The president will approve the creation and staffing of an Information Security department. • There have been no further breaches or incidents of the TMS since the investigation. • Employees will not be resistant to organizational restructuring. • TKU will continue to employ the TMS to manage student food purchases. • The recommended changes will not be reliant upon compatibility with existing food and beverage vendors. • TKU will continue to realize $600,000 in revenue from the TMS with a modest 0.5% growth per annum. • All recommended changes will be cost effective or cost neutral upon completion of a business case analysis. VI. Constraints Most project managers recognize the “iron triangle” of project constraints. It is said that a project can be done in a combination of two of three factors: well, quickly, or cheaply but not all three. If it’s to be done cheaply, it will likely be done quickly but not very well, etc. However, three more factors have been added: scope, benefits, and risk. Now a project can be done cheaply and quickly, but its’ scope must be extremely narrow, etc. (Siegelaub, 2007). Project Constraints For this specific projects, the constraints identified were cost, scope, and benefits vs. risk. TKU, as a public university, has limited funds available for cybersecurity. Furthermore, the benefits of protecting the TMS cannot cost more than the realized revenue from the system. As securing the 13 Project #5: Implementation Plan school’s entire network could be cost-prohibitive, the scope was kept extremely narrow to only include the TMS itself. Critical Project Barriers The main barrier to successful project completion is lack of commitment from leadership. If all levels of management are not invested and dedicated to securing the TMS, then they will not make the decisions and expenditures needed to complete the project. This leads to the second barrier, which is cost. Additional, qualified personnel could be prohibitively expensive when viewed through the context of securing only the TMS. However, the additional security staff would be able to be cross-utilized for other school networks, which would realize a cost savings. Lastly, organizational resistance to change, and an unwillingness to improve cybersecurity among employees will ensure that this project fails. VII. Proposed Network Architecture (TMS only) Below is the proposed architecture for the updated TMS system. 14 Project #5: Implementation Plan 15 Project #5: Implementation Plan References Ayyagari, R., & Tyks, J. (2012). Disaster at a University: A Case Study in Information Security. Journal of Information Technology Education, 11, 85-96. Retrieved from https://learn.umuc.edu/d2l/lms/dropbox/user/folder_submit_files.d2l?db=699088&grpid=0&is prv=0&bp=0&ou=326948 CSO Staff. (2016, January 25). Security policy samples, templates and tools. Retrieved from CSO: https://www.csoonline.com/article/3019126/security/security-policy-samples-templates-andtools.html Kissel, R., Stine, K., Scholl , M., Rossman, H., Fahlsing, J., & Gulick, J. (2008, October). NIST Special Publication 800-64 Revision 2: I N F O R M A T I O N S E C U R I T Y. Retrieved from National Institute of Standards and Technology: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-64r2.pdf Mochal, T. (2017). Defining Project Goals and Objectives. Retrieved from KIDASA Software: https://kidasa.com/defining-project-goals-and-objectives/ Morgan, S. (2016, January 9). Top Cyber Security Salaries In U.S. Metros Hit $380,000. Retrieved from Forbes: https://www.forbes.com/sites/stevemorgan/2016/01/09/top-cyber-security-salaries-inu-s-metros-hit-380000/#599b12d17ef8 PayScale. (2018). Average Cyber Security Analyst Salary. Retrieved from PayScale: https://www.payscale.com/research/US/Job=Cyber_Security_Analyst/Salary PCI Security Standards Council. (2018). PCI Security. Retrieved from PCI Security Standards Council: https://www.pcisecuritystandards.org/pci_security/ Rouse, M. (2018). project scope . Retrieved from CIO: Tech Target: https://searchcio.techtarget.com/definition/project-scope Siegelaub, J. M. (2007). Six (yes six!) constraints: an enhanced model for project control. Retrieved from Project Management Institute: https://www.pmi.org/learning/library/six-constraints-enhancedmodel-project-control-7294 Vanden Bos, P. (2010, June 29). How to Set Business Goals . Retrieved from INC: https://www.inc.com/guides/2010/06/setting-business-goals.html Wilson, M., & Hash, J. (2003, October). NIST Special Publication 800-50: Building an Information Technology Security Awareness and Training Program . Retrieved from National Institute of Standards and Technology: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-50.pdf 16 Project #5: Implementation Plan 17 
Purchase answer to see full attachment