Information technology Networking ICTNWK510 Develop, implement and evaluate system and application security Learner Materials and Assessment Tasks 1|Page Table of Contents About ICTNWK510 Develop, implement and evaluate system and application security .................... 5 Identify enterprise ICT system or application security policies .......................................................... 10 Activity 1 ............................................................................................................................................... 17 Identify security requirements for the ICT system or application...................................................... 38 Activity 2 ............................................................................................................................................... 49 Write an ICT system or application security plan according to the enterprise and ICT system or application security policies................................................................................................................. 58 Activity 3 ............................................................................................................................................... 90 Identify standards against which to engineer the ICT system or application .................................... 95 Activity 4 ............................................................................................................................................... 99 Identify criteria for performing risk based audits against the ICT system or application ............... 102 Activity 5 ............................................................................................................................................. 115 Develop processes and procedures to mitigate the introduction of vulnerabilities during the engineering process ........................................................................................................................... 129 Activity 6 ............................................................................................................................................. 144 Integrate applicable information security requirements, controls, processes, and procedures into ICT system and application design specifications according to established requirements ............. 158 Execute enterprise and ICT system or application security policies ................................................ 169 Activity 7 ............................................................................................................................................. 174 Apply and verify compliance with identified standards against which to engineer the ICT system or application .......................................................................................................................................... 177 Activity 8 ............................................................................................................................................. 181 Perform processes and procedures to mitigate the introduction of vulnerabilities during the engineering process ........................................................................................................................... 184 Perform secure configuration management practices ..................................................................... 188 Activity 9 ............................................................................................................................................. 198 Validate that the engineered ICT system and application security controls meet the specified requirements ...................................................................................................................................... 202 Re-engineer security controls to mitigate vulnerabilities identified during the operations phase 204 Ensure integration of information security practices throughout the SDLC process ...................... 204 Document ICT system or application security controls addressed within the system .................... 205 Practise secure coding ........................................................................................................................ 206 Activity 10 ........................................................................................................................................... 210 Review new and existing risk management technologies to achieve an optimal enterprise risk posture................................................................................................................................................ 213 2|Page Review new and existing ICT security technologies to support secure engineering across the SDLC phases ................................................................................................................................................. 214 Continually assess effectiveness of the information system controls based on risk management practices and procedures ................................................................................................................... 215 Assess and evaluate system compliance with corporate policies and architectures ...................... 225 Assess system maturation and readiness for promotion to the production stage ......................... 228 Collect lessons learned from integration of information security into the SDLC and use to identify improvement actions ......................................................................................................................... 231 Activity 11 ........................................................................................................................................... 238 Collect, analyse and report performance measures ......................................................................... 240 Activity 12 ........................................................................................................................................... 241 Additional Reference Materials Students should have access to: AS/NZS ISO/IEC 38500:2010 ISO/IEC 38500:2008 Australian/New Zealand Standard™ Corporate governance of information technology 3|Page seDownload from: http://www.professionalsaustralia.org.au/information-technology/wpcontent/uploads/sites/41/2014/11/Standards-Australia-Corporate-Governance-of-IT1.pdf 4|Page About ICTNWK510 Develop, implement and evaluate system and application security Application This unit describes the skills and knowledge required to develop, implement and evaluate information security in an information and communications technology (ICT) system or application during the system development life cycle (SDLC), prior to the operations and maintenance phase. It applies to individuals with excellent information and communications technology (ICT) expertise who are working as network managers and are required to handle system and application security from the development phase through implementation to evaluation. No licensing, legislative or certification requirements apply to this unit at the time of publication. Unit Sector Networking Elements and Performance Criteria ELEMENT PERFORMANCE CRITERIA Elements describe the Performance criteria describe the performance needed to essential outcomes. demonstrate achievement of the element. 1. Develop system and 1.1 Identify enterprise ICT system or application security policies application security 1.2 Identify security requirements for the ICT system or application 1.3 Write an ICT system or application security plan according to the enterprise and ICT system or application security policies 1.4 Identify standards against which to engineer the ICT system or application 1.5 Identify criteria for performing risk based audits against the ICT system or application 1.6 Develop processes and procedures to mitigate the introduction of vulnerabilities during the engineering process 1.7 Integrate applicable information security requirements, controls, processes, and procedures into ICT system and application design specifications according to established requirements 5|Page 2. Implement system and application security 2.1 Execute enterprise and ICT system or application security policies 2.2 Apply and verify compliance with identified standards against which to engineer the ICT system or application 2.3 Perform processes and procedures to mitigate the introduction of vulnerabilities during the engineering process 2.4 Perform secure configuration management practices 2.5 Validate that the engineered ICT system and application security controls meet the specified requirements 2.6 Re-engineer security controls to mitigate vulnerabilities identified during the operations phase 2.7 Ensure integration of information security practices throughout the SDLC process 2.8 Document ICT system or application security controls addressed within the system 3. Evaluate system and application security 2.9 Practise secure coding 3.1 Review new and existing risk management technologies to achieve an optimal enterprise risk posture 3.2 Review new and existing ICT security technologies to support secure engineering across the SDLC phases 3.3 Continually assess effectiveness of the information system controls based on risk management practices and procedures 3.4 Assess and evaluate system compliance with corporate policies and architectures 3.5 Assess system maturation and readiness for promotion to the production stage 3.6 Collect lessons learned from integration of information security into the SDLC and use to identify improvement actions 3.7 Collect, analyse and report performance measures 6|Page Foundation Skills This section describes language, literacy, numeracy and employment skills incorporated in the performance criteria that are required for competent performance. Skill Learning Performance Criteria 3.6 Description Builds on prior knowledge and experience to clarify, extend understanding and contribute to ongoing organisational improvement Reading 1.1-1.4, 1.7, 2.2, 3.4, 3.7 Gathers, interprets and analyses technical and regulatory information to determine requirements according to client needs Writing 1.3, 2.8, 3.7 Uses factual information and industry related terminology to produce workplace documents Oral Communication 3.7 Conveys information about performance measures clearly, using specific and relevant language suitable to audience Uses listening and questioning techniques to confirm understanding Navigate the world of work 1.1, 1.3, 1.7 Takes full responsibility for identifying and considering relevant policies and legislative requirements in the development of system security processes Get the work done 1.5-1.7, 2.1, 2.3-2.7, 2.9, 3.1-3.5 Demonstrates a sophisticated understanding of principles, concepts, language and practices associated with the digital world and uses these to troubleshoot and reduce risks Uses digital tools to access and organise complex data and analyse multiple sources of information for strategic purposes Is acutely aware of the importance of understanding, monitoring and controlling access to digitally stored and transmitted information Uses a combination of formal and logical planning processes and an increasingly intuitive understanding of context to identify relevant information and risks 7|Page Unit Mapping Information Code and title Code and title current version ICTNWK510 Develop, implement and evaluate system and application security previous version ICANWK510A Develop, implement and evaluate system and application security Makes a range of critical decisions in relatively complex situations, taking a range of constraints into account Comments Equivalence status Updated to meet Standards for Equivalent unit Training Packages Assessment requirements Modification History Release Release 1 Comments This version first released with ICT Information and Communications Technology Training Package Version 1.0. Performance Evidence Evidence of the ability to: create an information and communications technology (ICT) system or application security plan implement system and application security apply and verify compliance with the identified standards practise secure coding practices assess and evaluate system compliance. Note: If a specific volume or frequency is not stated, then evidence must be provided at least once. Knowledge Evidence To complete the unit requirements safely and effectively, the individual must: summarise a range of programming languages, including those used by the organisation summarise best practice in application of language syntax rules explain data structures outline graphical user interfaces (GUIs) summarise small-size application development 8|Page identify and summarise the legislation, regulations and codes of practice that impact on network security describe the risk assessment process required in evaluating system vulnerabilities, including: risk mitigation security control selection implementation and evaluation process software security standards compliance. 9|Page Identify enterprise ICT system or application security policies System Development Life Cycle Phases1 1- System Planning The Planning phase is the most crucial step in creating a successful system, during this phase you decide exactly what you want to do and the problems you’re trying to solve, by: Defining the problems, the objectives and the resources such as personnel and costs. Studying the ability of proposing alternative solutions after meeting with clients, suppliers, consultants and employees. Studying how to make your product better than your competitors’. After analyzing this data you will have three choices: develop a new system, improve the current system or leave the system as it is. 2- System Analysis The end-user’s requirements should be determined and documented, what their expectations are for the system, and how it will perform. A feasibility study will be made for the project as well, involving determining whether it’s organizationally, economically, socially, technologically feasible. 1 Source: Airbrake, as at https://airbrake.io/blog/sdlc/what-is-system-development-life-cycle, as on 10th May, 2017. 10 | P a g e it’s very important to maintain strong communication level with the clients to make sure you have a clear vision of the finished product and its function. 3- System Design The design phase comes after a good understanding of customer’s requirements, this phase defines the elements of a system, the components, the security level, modules, architecture and the different interfaces and type of data that goes through the system. A general system design can be done with a pen and a piece of paper to determine how the system will look like and how it will function, and then a detailed and expanded system design is produced, and it will meet all functional and technical requirements, logically and physically. 4- Implementation and Deployment This phase comes after a complete understanding of system requirements and specifications, it’s the actual construction process after having a complete and illustrated design for the requested system. In the Software Development Life Cycle, the actual code is written here, and if the system contains hardware, then the implementation phase will contain configuration and fine-tuning for the hardware to meet certain requirements and functions. In this phase, the system is ready to be deployed and installed in customer’s premises, ready to become running, live and productive, training may be required for end users to make sure they know how to use the system and to get familiar with it, the implementation phase may take a long time and that depends on the complexity of the system and the solution it presents. 5- System Testing and Integration Bringing different components and subsystems together to create the whole integrated system, and then Introducing the system to different inputs to obtain and analyze its outputs and behavior and the way it functions. Testing is becoming more and more important to ensure customer’s satisfaction, and it requires no knowledge in coding, hardware configuration or design. Testing can be performed by real users, or by a team of specialized personnel, it can also be systematic and automated to ensure that the actual outcomes are compared and equal to the predicted and desired outcomes. 6- System Maintenance In this phase, periodic maintenance for the system will be carried out to make sure that the system won’t become obsolete, this will include replacing the old hardware and continuously evaluating system’s performance, it also includes providing latest updates for certain components to make sure it meets the right standards and the latest technologies to face current security threats. 11 | P a g e These are the main six phases of the System Development Life Cycle, and it’s an iterative process for each project. It’s important to mention that excellent communication level should be maintained with the customer, and Prototypes are very important and helpful when it comes to meeting the requirements. By building the system in short iterations; we can guarantee meeting the customer’s requirements before we build the whole system. Many models of system development life cycle came up from the idea of saving effort, money and time, in addition to minimizing the risk of not meeting the customer’s requirement at the end of project, some of these models are SDLC Iterative Model, and SDLC Agile Model. In business, a security policy is a document that states in writing how a company plans to protect the company's physical and information technology (IT) assets. A security policy is often considered to be a "living document", meaning that the document is never finished, but is continuously updated as technology and employee requirements change. A company's security policy may include an acceptable use policy, a description of how the company plans to educate its employees about protecting the company's assets, an explanation of how security measurements will be carried out and enforced, and a procedure for evaluating the effectiveness of the security policy to ensure that necessary corrections will be made2. ICT security policies by enterprise size, sector and country3 The existence of an ICT security policy in an enterprise means that the enterprise is aware of the importance of its ICT systems and the relevant potential risks. Moreover, the existence of an ICT security policy would imply an enterprise's strategy to safeguard data and ICT systems as well as mandatory obligations for all employees. In 2015, 32 % of enterprises in the EU-28 had a formally defined ICT security policy; shares of over 45 % were registered in Sweden and Portugal (51 % and 49 % respectively). In the context of this article, a formally defined policy should refer to an assessment of ICT security risks in terms of likelihood of occurrence of incidents and their possible impact on the operations of the enterprise. In addition, a policy should describe the various actors and their responsibilities in relation to incident handling and possible contingency plans. Figure 1 shows that the share of large enterprises that had a formally defined ICT security policy was almost three times the share of small ones. The highest proportions of enterprises having such a policy in the EU-28 was reported by enterprises in the sector of Information and communication activities (60 %) as well as by enterprises with Professional, scientific and technical activities (49 %) (Figure 2). The lowest proportions were registered in the sectors of Construction (20 %), Real estate (25 %) and Transportation and storage (26 %) . It is assumed that the existence of ICT security policy and the frequency of reviewing it is positively correlated to the readiness of the enterprises to report ICT security incidents. Out of all EU 2 Source: Tech Target, as at http://searchsecurity.techtarget.com/definition/security-policy, as on 8th May, 2017. 3 Source: Eurostat, as at http://ec.europa.eu/eurostat/statisticsexplained/index.php/ICT_security_in_enterprises, as on 8th May, 2017. 12 | P a g e enterprises that reported having an ICT security policy (32 %) the majority of them reported having defined or reviewed their policy within the last 12 months (20 %) (Figure 3). The highest percentage of enterprises that most recently defined or reviewed their policy was reported in Ireland (30 %), Croatia and Portugal (both 29 %). Some (40 %) of enterprises in Information and communication activities – highest proportion among all economic activities – reported having defined or reviewed their ICT policy in the last 12 months (Figure 4). Types of risks The risk of destruction or corruption of data due to an attack or some other unexpected incident is the risk mostly addressed by enterprises’ ICT security policies. The three types of risks addressed by enterprises having a formally defined ICT security policy correspond essentially to the core elements of the ICT security definition, i.e. integrity, confidentiality and availability of data and systems. These elements are further described in the following section of this article. The highest percentage of enterprises with a formally defined ICT security policy addressing the risks of destruction or corruption of data due to an attack or some other unexpected incident was reported in Portugal (44 %). Similarly enterprises in Portugal reported the second highest percentage with a formally defined ICT security policy addressing the risks of unavailability of ICT services due to an attack from outside (e.g. Denial of Service attack) (35 %). The highest percentage of enterprises with a formally defined ICT security policy addressing the risks of disclosure of confidential data due to intrusion, pharming, phishing attacks or by accident was reported in Ireland (39 %). In addition, enterprises in Ireland reported the highest percentage with a formally defined ICT security policy addressing all the above mentioned risks (35 %). Data sources and availability Source: Data presented in this article are based on the results of the 2015 Community survey on 'ICT usage and e-commerce in enterprises'. Statistics were obtained from surveys in enterprises conducted by National Statistical Authorities in the first months of 2015. 13 | P a g e Sample: Some 148 800 enterprises, with 10 or more persons employed, out of 1.5 million in EU-28 were surveyed. Out of these 1.5 million enterprises approximately 83 % were enterprises with 10-49 persons employed, 14 % with 50-249 and 3 % with 250 or more. Symbols: Data in tables shown as ‘:’ refer to data that are unavailable, unreliable, confidential or not applicable. Unreliable data are included in the calculation of European aggregates. Data presented in this article may differ from the data in the database on account of updates made after the data extractions used for this article. Main concepts: The surveys' reference period was the current situation of the survey period or for some questions (like e.g. e-commerce) the year 2014. The observation statistical unit is the enterprise, as defined in the Regulation 696/1993 of 15 March 1993. The survey covered enterprises with at least 10 persons employed. Economic activities correspond to the classification NACE Revision 2. The sectors covered are manufacturing, electricity, gas and steam, water supply, construction, wholesale and retail trades, repair of motor vehicles and motorcycles, transportation and storage, accommodation and food service activities, information and communication, real estate, professional, scientific and technical activities, administrative and support activities and repair of computers and communication equipment. Enterprises are broken down by size; small (1049), medium (50-249) and large enterprises (250 or more persons employed). ICT-related security incidents affect the ICT system of an enterprise and may cause different problems. Therefore, the following security risks were expected to be addressed by the enterprises' ICT security policies : Destruction or corruption of data due to hardware or software failures refers to issues of data integrity caused by hardware or software failures, e.g. crashes of servers or hard disks due to hardware failures or crashes of servers due to software failures, e.g. erroneous updates. Unavailability of ICT services due to attack from outside refers to attempts from outside to make an information system resource unavailable to its intended users. One aim of these attacks is to prevent an internet site or service from functioning efficiently, e.g. websites of banks, credit card payment gateways. Disclosure of confidential data due to intrusion, pharming, phishing attacks refers to an attempt to get confidential information on persons, staff or clients, intellectual property or other confidential information. Intrusion is an attempt to bypass security controls on an information system by viruses, worms, Trojan horses etc. Phishing is a criminally fraudulent attempt to acquire sensitive information such as usernames, passwords and credit card details by masquerading as a trustworthy entity in an electronic communication. Pharming is an attack which redirects the traffic of a website to another, bogus website in order to acquire sensitive information. The evolution of computer networks has made the sharing of information ever more prevalent. Information is now exchanged at the rate of trillions of bytes per millisecond, daily numbers that might extend beyond comprehension or available nomenclature. A proportion of that data is not intended for sharing beyond a limited group and much data is protected by law or intellectual property. 14 | P a g e An information security policy endeavors to enact those protections and limit the distribution of data not in the public domain to authorized recipients4. Every organization needs to protect its data and also control how it should be distributed both within and without the organizational boundaries. This may mean that information may have to be encrypted, authorized through a third party or institution and may have restrictions placed on its distribution with reference to a classification system laid out in the information security policy. An example of the use of an information security policy might be in a data storage facility which stores database records on behalf of medical facilities. These records are sensitive and cannot be shared, under penalty of law, with any unauthorized recipient whether a real person or another device. An information security policy would be enabled within the software that the facility uses to manage the data they are responsible for. In addition, workers would generally be contractually bound to comply with such a policy and would have to have sight of it prior to operating the data management software. A business might employ an information security policy to protect its digital assets and intellectual rights in efforts to prevent theft of industrial secrets and information that could benefit competitors. A typical security policy might be hierarchical and apply differently depending on whom they apply to. For example, the secretarial staff who type all the communications of an organization are usually bound never to share any information unless explicitly authorized, whereby a more senior manager may be deemed authoritative enough to decide what information produced by the secretaries can be shared, and to who, so they are not bound by the same information security policy terms. To cover the whole organization therefore, information security policies frequently contain different specifications depending upon the authoritative status of the persons they apply to. A good security policy takes into consideration the mission of the organization, the critical assets requiring protection, the threats posed and the mitigating risks against known vulnerabilities. These are all parts of a risk assessment that includes a business-impact analysis, which identifies the weaknesses, the critical assets and the effect on the company if a vulnerability were exploited5. Developing a security policy isn't a daunting task once the scope is identified using this simple explanation. The challenges are in defining the scope and writing a policy that can be embraced by other areas of the organization. By definition, the policy is the high-level document that's used to guide the formulation of procedures and guidelines. The policy answers the question of "What should be done and by whom?" The procedures and guidelines answer the question of "How should it be done?" 4 Source: Technopedia, as at https://www.techopedia.com/definition/24838/information-security-policy, as on 8th May, 2017. 5 Source: Computer World, as at http://www.computerworld.com/article/2569303/security0/how-to-developan-enterprise-security-policy.html, as on 8th May, 2017. 15 | P a g e Below are some tips for developing a comprehensive enterprise security policy. It's a checklist for any policy wonk given the responsibility of putting the document together. 1. Know your organization. Without a realistic understanding of the organizational structure -the players, the environment, the mission, goals and objectives -- it's exceedingly difficult to write a policy that will fit. Therefore, knowing the lay of the land -- the hierarchy and the roles and responsibilities of different areas -- is very important. 2. Define the scope and the agenda. What will the policy cover? This should be stated upfront in the policy document. Equally important is what it won't cover. If you can derive both, it will be meaningful to the people who need to translate the policy to practical procedures and/or guidelines. 3. Know your target audience. Who are the stakeholders for the various sections of the document? Who will be reading and signing off on it? The CEO, CIO and CISO are normally the key stakeholders, and each has a specific agenda that should be addressed. For the CEO, it would be the areas derived from the business-impact analysis; for the CIO, it would be the overall enterprise architecture and infrastructure that aligns and enables the CEO and the organizational mission; and for the CISO, it should address the critical infrastructure and assets, along with risk, vulnerability and mitigation focus. 4. Stay high-level, general and broad. These are critical points that need to be remembered as each policy statement is written. Going too far down in the weeds leads to the area of procedures, so it's important to keep the policy statements at the appropriate level and aligned with the mission. 5. Ensure that it can be easily translated to procedures and guidelines by the appropriate areas. Try a small sample, imagine the area to which the policy might apply and see if you can easily derive a procedure or guideline. After all, you might be asked for some examples down the road by less-experienced managers. 6. Keep weaknesses and organizational deficiencies in mind so the policy can address specific areas while staying aligned with your goals. Recognize the gaps and try to bridge them through policies. Keep the mission and business-impact analysis in mind. These are critical to effective policies that supplant the gaps in organizational functionality. 7. Be aware of external drivers. Depending on your industry, there may be regulatory requirements or cross-cutting laws. The policy should address the requirements to ensure compliance and make your organization a model. 8. Be realistic. If you can get a first cut past the approving authorities, it's a step in the right direction. Policies can never be static because the environment and organizational operations are always changing. Companies on the leading edge are dynamic in nature, and gaining competitive advantage requires continuous change and improvement. A policy that addresses 90% of the needs and is implemented is better than one that aims for 100% but never gets out of draft mode. 9. Ensure version control and backups. This seems like common sense, but you'd be surprised at how many organizations don't maintain tight version control, including documented procedures for modifications along with a good single backup strategy. You never want to end up hunting for the most current policy document, nor should you ever question its integrity. This in itself may require a policy. 16 | P a g e 10. Avoid controversy. This of course depends on how well the policy is rolled out and what changes are made. If change is required, do it incrementally. It hurts less. Having the backing of senior executive leadership is also important in the event that critical gaps require immediate change. 11. Wear a white hat. Remember, the whole reason for developing security policies is to benefit the organization and its personnel. If you are given the task of getting the job done, try to get acceptance from the key managers sooner rather than later. An effective policy development effort has collaboration written all over it. And, done properly, it can even be fun. 12. Finally, don't forget to smile and keep your sense of humor. It can be an intense effort, but by using proven project management methods, including milestones and timing, you can ensure that the important pieces are addressed first and that stress is minimized. It comes down to having a good road map, a strategy and a flashlight. Activity 1 Where in an organisation are you likely to find its ICT security policy? 17 | P a g e Activity 1 18 | P a g e Sample Policies6 Acquisition Assessment Policy 1. Overview The process of integrating a newly acquired company can have a drastic impact on the security poster of either the parent company or the child company. The network and security infrastructure of both entities may vary greatly and the workforce of the new company may have a drastically different culture and tolerance to openness. The goal of the security acquisition assessment and integration process should include: Assess company’s security landscape, posture, and policies Protect both <Company Name> and the acquired company from increased security risks Educate acquired company about <Company Name> policies and standard Adopt and implement <Company Name> Security Policies and Standards Integrate acquired company 6 Source: SANS, as at https://www.sans.org/security-resources/policies/network-security#acquisitionassessment-policy, as on 8th May, 2017. 19 | P a g e Continuous monitoring and auditing of the acquisition 2. Purpose The purpose of this policy is to establish Infosec responsibilities regarding corporate acquisitions, and define the minimum security requirements of an Infosec acquisition assessment. 3. Scope This policy applies to all companies acquired by <Company Name> and pertains to all systems, networks, laboratories, test equipment, hardware, software and firmware, owned and/or operated by the acquired company. 4. Policy 4.1 General Acquisition assessments are conducted to ensure that a company being acquired by <Company Name> does not pose a security risk to corporate networks, internal systems, and/or confidential/sensitive information. The Infosec Team will provide personnel to serve as active members of the acquisition team throughout the entire acquisition process. The Infosec role is to detect and evaluate information security risk, develop a remediation plan with the affected parties for the identified risk, and work with the acquisitions team to implement solutions for any identified security risks, prior to allowing connectivity to <Company Name>'s networks. Below are the minimum requirements that the acquired company must meet before being connected to the <Company Name> network. 4.2 Requirements 4.2.1 Hosts 4.2.1.1 All hosts (servers, desktops, laptops) will be replaced or re-imaged with a <Company Name> standard image or will be required to adopt the minimum standards for end user devices. 4.2.1.2 Business critical production servers that cannot be replaced or re-imaged must be audited and a waiver granted by Infosec. 4.2.1.3 All PC based hosts will require <Company Name> approved virus protection before the network connection. 4.2.2 Networks 4.2.2.1 All network devices will be replaced or re-imaged with a <Company Name> standard image. 4.2.2.2 Wireless network access points will be configured to the <Company Name> standard. 4.2.3 Internet 4.2.3.1 All Internet connections will be terminated. 4.2.3.2 When justified by business requirements, air-gapped Internet connections require Infosec review and approval. 4.2.4 Remote Access 4.2.4.1 All remote access connections will be terminated. 20 | P a g e 4.2.4.2 Remote access to the production network will be provided by <Company Name>. 4.2.5 Labs 4.2.5.1 Lab equipment must be physically separated and secured from non-lab areas. 4.2.5.2 The lab network must be separated from the corporate production network with a firewall between the two networks. 4.2.5.3 Any direct network connections (including analog lines, ISDN lines, T1, etc.) to external customers, partners, etc., must be reviewed and approved by the Lab Security Group (LabSec). 4.2.5.4 All acquired labs must meet with LabSec lab policy, or be granted a waiver by LabSec. 4.2.5.5 In the event the acquired networks and computer systems being connected to the corporate network fail to meet these requirements, the <Company Name> Chief Information Officer (CIO) must acknowledge and approve of the risk to <Company Name>'s networks 5. Policy Compliance 5.1 Compliance Measurement The Infosec team will verify compliance to this policy through various methods, including but not limited to, business tool reports, internal and external audits, and feedback to the policy owner. 5.2 Exceptions Any exception to the policy must be approved by the Infosec team in advance. 5.3 Non-Compliance An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment. 6 Related Standards, Policies and Processes None. 7 Definitions and Terms The following definition and terms can be found in the SANS Glossary located at: https://www.sans.org/security-resources/glossary-of-terms/ Business Critical Production Server 21 | P a g e 8 Revision History Date of Change Responsible Summary of Change Bluetooth Baseline Requirements Policy 1. Overview Bluetooth enabled devices are exploding on the Internet at an astonishing rate. At the range of connectivity has increased substantially. Insecure Bluetooth connections can introduce a number of potential serious security issues. Hence, there is a need for a minimum standard for connecting Bluetooth enable devices. 2. Purpose The purpose of this policy is to provide a minimum baseline standard for connecting Bluetooth enabled devices to the <Company Name> network or <Company Name> owned devices. The intent of the minimum standard is to ensure sufficient protection Personally Identifiable Information (PII) and confidential <Company Name> data. 3. Scope This policy applies to any Bluetooth enabled device that is connected to <Company Name> network or owned devices. 4. Policy 4.1 Version No Bluetooth Device shall be deployed on <Company Name> equipment that does not meet a minimum of Bluetooth v2.1 specifications without written authorization from the Infosec Team. Any Bluetooth equipment purchased prior to this policy must comply with all parts of this policy except the Bluetooth version specifications. 4.2 Pins and Pairing When pairing your Bluetooth unit to your Bluetooth enabled equipment (i.e. phone, laptop, etc.), ensure that you are not in a public area where you PIN can be compromised. If your Bluetooth enabled equipment asks for you to enter your pin after you have initially paired it, you must refuse the pairing request and report it to Infosec, through your Help Desk, immediately. 4.3 Device Security Settings 22 | P a g e All Bluetooth devices shall employ ‘security mode 3’ which encrypts traffic in both directions, between your Bluetooth Device and its paired equipment. Use a minimum PIN length of 8. A longer PIN provides more security. Switch the Bluetooth device to use the hidden mode (non-discoverable) Only activate Bluetooth only when it is needed. Ensure device firmware is up-to-date. 4.4 Security Audits The Infosec Team may perform random audits to ensure compliancy with this policy. In the process of performing such audits, Infosec Team members shall not eavesdrop on any phone conversation. 4.5 Unauthorized Use The following is a list of unauthorized uses of <Company Name>-owned Bluetooth devices: Eavesdropping, device ID spoofing, DoS attacks, or any form of attacking other Bluetooth enabled devices. Using <Company Name>-owned Bluetooth equipment on non-<Company Name>-owned Bluetooth enabled devices. Unauthorized modification of Bluetooth devices for any purpose. 4.6 User Responsibilities It is the Bluetooth user's responsibility to comply with this policy. Bluetooth mode must be turned off when not in use. PII and/or <Company Name> Confidential or Sensitive data must not be transmitted or stored on Bluetooth enabled devices. Bluetooth users must only access <Company Name> information systems using approved Bluetooth device hardware, software, solutions, and connections. Bluetooth device hardware, software, solutions, and connections that do not meet the standards of this policy shall not be authorized for deployment. Bluetooth users must act appropriately to protect information, network access, passwords, cryptographic keys, and Bluetooth equipment. Bluetooth users are required to report any misuse, loss, or theft of Bluetooth devices or systems immediately to Infosec. 5. Policy Compliance 8.1 Compliance Measurement The Infosec Team will verify compliance to this policy through various methods, including but not limited to, periodic walk-thrus, video monitoring, business tool reports, internal and external audits, and feedback to the policy owner. 8.2 Exceptions Any exception to the policy must be approved by the Infosec Team in advance. 8.3 Non-Compliance An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment. 23 | P a g e 9 Related Standards, Policies and Processes None. 10 Definitions and Terms None. 11 Revision History Date of Change Responsible Summary of Change Remote Access Policy 1. Overview Remote access to our corporate network is essential to maintain our Team’s productivity, but in many cases this remote access originates from networks that may already be compromised or are at a significantly lower security posture than our corporate network. While these remote networks are beyond the control of Hypergolic Reactions, LLC policy, we must mitigate these external risks the best of our ability. 2. Purpose The purpose of this policy is to define rules and requirements for connecting to <Company Name>'s network from any host. These rules and requirements are designed to minimize the potential exposure to <Company Name> from damages which may result from unauthorized use of <Company Name> resources. Damages include the loss of sensitive or company confidential data, intellectual property, damage to public image, damage to critical <Company Name> internal systems, and fines or other financial liabilities incurred as a result of those losses. 3. Scope This policy applies to all <Company Name> employees, contractors, vendors and agents with a <Company Name>-owned or personally-owned computer or workstation used to connect to the <Company Name> network. This policy applies to remote access connections used to do work on behalf of <Company Name>, including reading or sending email and viewing intranet web resources. This policy covers any and all technical implementations of remote access used to connect to <Company Name> networks. 4. Policy It is the responsibility of <Company Name> employees, contractors, vendors and agents with remote access privileges to <Company Name>'s corporate network to ensure that their remote access connection is given the same consideration as the user's on-site connection to <Company Name>. 24 | P a g e General access to the Internet for recreational use through the <Company Name> network is strictly limited to <Company Name> employees, contractors, vendors and agents (hereafter referred to as “Authorized Users”). When accessing the <Company Name> network from a personal computer, Authorized Users are responsible for preventing access to any <Company Name> computer resources or data by non-Authorized Users. Performance of illegal activities through the <Company Name> network by any user (Authorized or otherwise) is prohibited. The Authorized User bears responsibility for and consequences of misuse of the Authorized User’s access. For further information and definitions, see the Acceptable Use Policy. Authorized Users will not use <Company Name> networks to access the Internet for outside business interests. For additional information regarding <Company Name>'s remote access connection options, including how to obtain a remote access login, free anti-virus software, troubleshooting, etc., go to the Remote Access Services website (company url). 4.1 Requirements 4.1.1 Secure remote access must be strictly controlled with encryption (i.e., Virtual Private Networks (VPNs)) and strong pass-phrases. For further information see the Acceptable Encryption Policy and the Password Policy. 4.1.2 Authorized Users shall protect their login and password, even from family members. 4.1.3 While using a <Company Name>-owned computer to remotely connect to <Company Name>'s corporate network, Authorized Users shall ensure the remote host is not connected to any other network at the same time, with the exception of personal networks that are under their complete control or under the complete control of an Authorized User or Third Party. 4.1.4 Use of external resources to conduct <Company Name> business must be approved in advance by InfoSec and the appropriate business unit manager. 4.1.5 All hosts that are connected to <Company Name> internal networks via remote access technologies must use the most up-to-date anti-virus software (place url to corporate software site here), this includes personal computers. Third party connections must comply with requirements as stated in the Third Party Agreement. 4.1.6 Personal equipment used to connect to <Company Name>'s networks must meet the requirements of <Company Name>-owned equipment for remote access as stated in the Hardware and Software Configuration Standards for Remote Access to <Company Name> Networks. 5. Policy Compliance 11.1 Compliance Measurement The Infosec Team will verify compliance to this policy through various methods, including but not limited to, periodic walk-thrus, video monitoring, business tool reports, internal and external audits, and inspection, and will provide feedback to the policy owner and appropriate business unit manager. 11.2 Exceptions Any exception to the policy must be approved by Remote Access Services and the Infosec Team in advance. 25 | P a g e 11.3 Non-Compliance An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment. 6 Related Standards, Policies and Processes Please review the following policies for details of protecting information when accessing the corporate network via remote access methods, and acceptable use of <Company Name>’s network: 7 Acceptable Encryption Policy Acceptable Use Policy Password Policy Third Party Agreement Hardware and Software Configuration Standards for Remote Access to <Company Name> Networks Revision History Date of Change Responsible Summary of Change Remote Access Tools Policy 1. Overview Remote desktop software, also known as remote access tools, provide a way for computer users and support staff alike to share screens, access work computer systems from home, and vice versa. Examples of such software include LogMeIn, GoToMyPC, VNC (Virtual Network Computing), and Windows Remote Desktop (RDP). While these tools can save significant time and money by eliminating travel and enabling collaboration, they also provide a back door into the <Company Name> network that can be used for theft of, unauthorized access to, or destruction of assets. As a result, only approved, monitored, and properly controlled remote access tools may be used on <Company Name> computer systems. 2. Purpose This policy defines the requirements for remote access tools used at <Company Name 3. Scope This policy applies to all remote access where either end of the communication terminates at a <Company Name> computer asset 26 | P a g e 4. Policy All remote access tools used to communicate between <Company Name> assets and other systems must comply with the following policy requirements. 4.1 Remote Access Tools <Company Name> provides mechanisms to collaborate between internal users, with external partners, and from non-<Company Name> systems. The approved software list can be obtained from <link-to-approved-remote-access-software-list>. Because proper configuration is important for secure use of these tools, mandatory configuration procedures are provided for each of the approved tools. The approved software list may change at any time, but the following requirements will be used for selecting approved products: a) All remote access tools or systems that allow communication to <Company Name> resources from the Internet or external partner systems must require multi-factor authentication. Examples include authentication tokens and smart cards that require an additional PIN or password. b) The authentication database source must be Active Directory or LDAP, and the authentication protocol must involve a challenge-response protocol that is not susceptible to replay attacks. The remote access tool must mutually authenticate both ends of the session. c) Remote access tools must support the <Company Name> application layer proxy rather than direct connections through the perimeter firewall(s). d) Remote access tools must support strong, end-to-end encryption of the remote access communication channels as specified in the <Company Name> network encryption protocols policy. e) All <Company Name> antivirus, data loss prevention, and other security systems must not be disabled, interfered with, or circumvented in any way. All remote access tools must be purchased through the standard <Company Name> procurement process, and the information technology group must approve the purchase. 5. Policy Compliance 7.1 Compliance Measurement The Infosec team will verify compliance to this policy through various methods, including but not limited to, periodic walk-thrus, video monitoring, business tool reports, internal and external audits, and feedback to the policy owner. 7.2 Exceptions Any exception to the policy must be approved by the Infosec Team in advance. 7.3 Non-Compliance An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment. 8 Related Standards, Policies and Processes None. 27 | P a g e 9 Definitions and Terms The following definition and terms can be found in the SANS Glossary located at: https://www.sans.org/security-resources/glossary-of-terms/ Application layer proxy 10 Revision History Date of Change Responsible Summary of Change Router and Switch Security Policy 1. Overview See Purpose. 2. Purpose This document describes a required minimal security configuration for all routers and switches connecting to a production network or used in a production capacity at or on behalf of <Company Name>. 3. Scope All employees, contractors, consultants, temporary and other workers at Cisco and its subsidiaries must adhere to this policy. All routers and switches connected to Cisco production networks are affected. 4. Policy Every router must meet the following configuration standards: 1. No local user accounts are configured on the router. Routers and switches must use TACACS+ for all user authentication. 2. The enable password on the router or switch must be kept in a secure encrypted form. The router or switch must have the enable password set to the current production router/switch password from the device’s support organization. 3. The following services or features must be disabled: a. IP directed broadcasts b. Incoming packets at the router/switch sourced with invalid addresses such as RFC1918 addresses 28 | P a g e 4. 5. 6. 7. 8. 9. 10. 11. c. TCP small services d. UDP small services e. All source routing and switching f. All web services running on router g. Cisco discovery protocol on Internet connected interfaces h. Telnet, FTP, and HTTP services i. Auto-configuration The following services should be disabled unless a business justification is provided: a. Cisco discovery protocol and other discovery protocols b. Dynamic trunking c. Scripting environments, such as the TCL shell The following services must be configured: a. Password-encryption b. NTP configured to a corporate standard source All routing updates shall be done using secure routing updates. Use corporate standardized SNMP community strings. Default strings, such as public or private must be removed. SNMP must be configured to use the most secure version of the protocol allowed for by the combination of the device and management systems. Access control lists must be used to limit the source and type of traffic that can terminate on the device itself. Access control lists for transiting the device are to be added as business needs arise. The router must be included in the corporate enterprise management system with a designated point of contact. Each router must have the following statement presented for all forms of login whether remote or local: "UNAUTHORIZED ACCESS TO THIS NETWORK DEVICE IS PROHIBITED. You must have explicit permission to access or configure this device. All activities performed on this device may be logged, and violations of this policy may result in disciplinary action, and may be reported to law enforcement. There is no right to privacy on this device. Use of this system shall constitute consent to monitoring." 12. Telnet may never be used across any network to manage a router, unless there is a secure tunnel protecting the entire communication path. SSH version 2 is the preferred management protocol. 13. Dynamic routing protocols must use authentication in routing updates sent to neighbors. Password hashing for the authentication string must be enabled when supported. 14. The corporate router configuration standard will define the category of sensitive routing and switching devices, and require additional services or configuration on sensitive devices including: a. IP access list accounting 29 | P a g e b. Device logging c. Incoming packets at the router sourced with invalid addresses, such as RFC1918 addresses, or those that could be used to spoof network traffic shall be dropped d. Router console and modem access must be restricted by additional security controls 5. Policy Compliance 10.1 Compliance Measurement The Infosec team will verify compliance to this policy through various methods, including but not limited to, periodic walk-thrus, video monitoring, business tool reports, internal and external audits, and feedback to the policy owner. 10.2 Exceptions Any exception to the policy must be approved by the Infosec team in advance. 10.3 Non-Compliance An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment. 6 Related Standards, Policies and Processes None. 7 Definitions and Terms None. 8 Revision History Date of Change Responsible Summary of Change Wireless Communication Policy 1. Overview With the mass explosion of Smart Phones and Tablets, pervasive wireless connectivity is almost a given at any organization. Insecure wireless configuration can provide an easy open door for malicious threat actors. 2. Purpose The purpose of this policy is to secure and protect the information assets owned by <Company Name>. <Company Name> provides computer devices, networks, and other electronic information systems to meet missions, goals, and initiatives. 30 | P a g e <Company Name> grants access to these resources as a privilege and must manage them responsibly to maintain the confidentiality, integrity, and availability of all information assets. This policy specifies the conditions that wireless infrastructure devices must satisfy to connect to <Company Name> network. Only those wireless infrastructure devices that meet the standards specified in this policy or are granted an exception by the Information Security Department are approved for connectivity to a <Company Name> network. 3. Scope All employees, contractors, consultants, temporary and other workers at <Company Name>, including all personnel affiliated with third parties that maintain a wireless infrastructure device on behalf of <Company Name> must adhere to this policy. This policy applies to all wireless infrastructure devices that connect to a <Company Name> network or reside on a <Company Name> site that provide wireless connectivity to endpoint devices including, but not limited to, laptops, desktops, cellular phones, and tablets. This includes any form of wireless communication device capable of transmitting packet data. 4. Policy 4.1 General Requirements All wireless infrastructure devices that reside at a <Company Name> site and connect to a <Company Name> network, or provide access to information classified as <Company Name> Confidential, or above must: Abide by the standards specified in the Wireless Communication Standard. Be installed, supported, and maintained by an approved support team. Use <Company Name> approved authentication protocols and infrastructure. Use <Company Name> approved encryption protocols. Maintain a hardware address (MAC address) that can be registered and tracked. Not interfere with wireless access deployments maintained by other support organizations. 4.2 Lab and Isolated Wireless Device Requirements All lab wireless infrastructure devices that provide access to <Company Name> Confidential or above, must adhere to section 4.1 above. Lab and isolated wireless devices that do not provide general network connectivity to the <Company Name> network must: Be isolated from the corporate network (that is it must not provide any corporate connectivity) and comply with the Lab Security Policy. Not interfere with wireless access deployments maintained by other support organizations. 4.3 Home Wireless Device Requirements 4.3.1 Wireless infrastructure devices that provide direct access to the <Company Name> corporate network, must conform to the Home Wireless Device Requirements as detailed in the Wireless Communication Standard. 31 | P a g e 4.3.2 Wireless infrastructure devices that fail to conform to the Home Wireless Device Requirements must be installed in a manner that prohibits direct access to the <Company Name> corporate network. Access to the <Company Name> corporate network through this device must use standard remote access authentication. 5. Policy Compliance 8.1 Compliance Measurement The Infosec team will verify compliance to this policy through various methods, including but not limited to, periodic walk-thrus, video monitoring, business tool reports, internal and external audits, and feedback to the policy owner. 8.2 Exceptions Any exception to the policy must be approved by the Infosec team in advance. 8.3 Non-Compliance An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment. 9 Related Standards, Policies and Processes Lab Security Policy Wireless Communication Standard 10 Definitions and Terms The following definition and terms can be found in the SANS Glossary located at: https://www.sans.org/security-resources/glossary-of-terms/ MAC Address 11 Revision History Date of Change Responsible Summary of Change Server Security Policy 1. Overview Unsecured and vulnerable servers continue to be a major entry point for malicious threat actors. Consistent Server installation policies, ownership and configuration management are all about doing the basics well. 32 | P a g e 2. Purpose The purpose of this policy is to establish standards for the base configuration of internal server equipment that is owned and/or operated by <Company Name>. Effective implementation of this policy will minimize unauthorized access to <Company Name> proprietary information and technology. 3. Scope All employees, contractors, consultants, temporary and other workers at Cisco and its subsidiaries must adhere to this policy. This policy applies to server equipment that is owned, operated, or leased by Cisco or registered under a Cisco-owned internal network domain. This policy specifies requirements for equipment on the internal Cisco network. For secure configuration of equipment external to Cisco on the DMZ, see the Internet DMZ Equipment Policy. 4. Policy 4.1 General Requirements 4.1.1 All internal servers deployed at <Company Name> must be owned by an operational group that is responsible for system administration. Approved server configuration guides must be established and maintained by each operational group, based on business needs and approved by InfoSec. Operational groups should monitor configuration compliance and implement an exception policy tailored to their environment. Each operational group must establish a process for changing the configuration guides, which includes review and approval by InfoSec. The following items must be met: Servers must be registered within the corporate enterprise management system. At a minimum, the following information is required to positively identify the point of contact: o Server contact(s) and location, and a backup contact o Hardware and Operating System/Version o Main functions and applications, if applicable Information in the corporate enterprise management system must be kept up-to-date. Configuration changes for production servers must follow the appropriate change management procedures 4.1.2 For security, compliance, and maintenance purposes, authorized personnel may monitor and audit equipment, systems, processes, and network traffic per the Audit Policy. 4.2 Configuration Requirements 4.2.1 Operating System configuration should be in accordance with approved InfoSec guidelines. 4.2.2 Services and applications that will not be used must be disabled where practical. 4.2.3 Access to services should be logged and/or protected through access-control methods such as a web application firewall, if possible. 33 | P a g e 4.2.4 4.2.5 4.2.6 4.2.7 4.2.8 4.2.9 The most recent security patches must be installed on the system as soon as practical, the only exception being when immediate application would interfere with business requirements. Trust relationships between systems are a security risk, and their use should be avoided. Do not use a trust relationship when some other method of communication is sufficient. Always use standard security principles of least required access to perform a function. Do not use root when a non-privileged account will do. If a methodology for secure channel connection is available (i.e., technically feasible), privileged access must be performed over secure channels, (e.g., encrypted network connections using SSH or IPSec). Servers should be physically located in an access-controlled environment. Servers are specifically prohibited from operating from uncontrolled cubicle areas. 4.3 Monitoring 4.3.1 All security-related events on critical or sensitive systems must be logged and audit trails saved as follows: All security related logs will be kept online for a minimum of 1 week. Daily incremental tape backups will be retained for at least 1 month. Weekly full tape backups of logs will be retained for at least 1 month. Monthly full backups will be retained for a minimum of 2 years. 4.3.2 Security-related events will be reported to InfoSec, who will review logs and report incidents to IT management. Corrective measures will be prescribed as needed. Security-related events include, but are not limited to: Port-scan attacks Evidence of unauthorized access to privileged accounts Anomalous occurrences that are not related to specific applications on the host. 5. Policy Compliance 11.1 Compliance Measurement The Infosec team will verify compliance to this policy through various methods, including but not limited to, periodic walk-thrus, video monitoring, business tool reports, internal and external audits, and feedback to the policy owner. 11.2 Exceptions Any exception to the policy must be approved by the Infosec team in advance. 11.3 Non-Compliance An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment. 6 Related Standards, Policies and Processes Audit Policy DMZ Equipment Policy 7 Definitions and Terms The following definition and terms can be found in the SANS Glossary located at: 34 | P a g e https://www.sans.org/security-resources/glossary-of-terms/ 8 De-militarized zone (DMZ) Revision History Date of Change Responsible Summary of Change Information Logging Standard 1. Overview Logging from critical systems, applications and services can provide key information and potential indicators of compromise. Although logging information may not be viewed on a daily basis, it is critical to have from a forensics standpoint. 2. Purpose The purpose of this document attempts to address this issue by identifying specific requirements that information systems must meet in order to generate appropriate audit logs and integrate with an enterprise’s log management function. The intention is that this language can easily be adapted for use in enterprise IT security policies and standards, and also in enterprise procurement standards and RFP templates. In this way, organizations can ensure that new IT systems, whether developed in-house or procured, support necessary audit logging and log management functions. 3. Scope This policy applies to all production systems on <Company Name> Network. 4. Standard 4.1 General Requirements All systems that handle confidential information, accept network connections, or make access control (authentication and authorization) decisions shall record and retain audit-logging information sufficient to answer the following questions: 1. What activity was performed? 2. Who or what performed the activity, including where or on what system the activity was performed from (subject)? 3. What the activity was performed on (object)? 35 | P a g e 4. When was the activity performed? 5. What tool(s) was the activity was performed with? 6. What was the status (such as success vs. failure), outcome, or result of the activity? 7. 4.2 Activities to be Logged Therefore, logs shall be created whenever any of the following activities are requested to be performed by the system: 1. Create, read, update, or delete confidential information, including confidential authentication information such as passwords; 2. Create, update, or delete information not covered in #1; 3. Initiate a network connection; 4. Accept a network connection; 5. User authentication and authorization for activities covered in #1 or #2 such as user login and logout; 6. Grant, modify, or revoke access rights, including adding a new user or group, changing user privilege levels, changing file permissions, changing database object permissions, changing firewall rules, and user password changes; 7. System, network, or services configuration changes, including installation of software patches and updates, or other installed software changes; 8. Application process startup, shutdown, or restart; 9. Application process abort, failure, or abnormal end, especially due to resource exhaustion or reaching a resource limit or threshold (such as for CPU, memory, network connections, network bandwidth, disk space, or other resources), the failure of network services such as DHCP or DNS, or hardware fault; and 10. Detection of suspicious/malicious activity such as from an Intrusion Detection or Prevention System (IDS/IPS), anti-virus system, or anti-spyware system. 4.3 Elements of the Log Such logs shall identify or contain at least the following elements, directly or indirectly. In this context, the term “indirectly” means unambiguously inferred. 1. Type of action – examples include authorize, create, read, update, delete, and accept network connection. 2. Subsystem performing the action – examples include process or transaction name, process or transaction identifier. 3. Identifiers (as many as available) for the subject requesting the action – examples include user name, computer name, IP address, and MAC address. Note that such identifiers should be standardized in order to facilitate log correlation. 36 | P a g e 4. Identifiers (as many as available) for the object the action was performed on – examples include file names accessed, unique identifiers of records accessed in a database, query parameters used to determine records accessed in a database, computer name, IP address, and MAC address. Note that such identifiers should be standardized in order to facilitate log correlation. 5. Before and after values when action involves updating a data element, if feasible. 6. Date and time the action was performed, including relevant time-zone information if not in Coordinated Universal Time. 7. Whether the action was allowed or denied by access-control mechanisms. 8. Description and/or reason-codes of why the action was denied by the access-control mechanism, if applicable. 4.4 Formatting and Storage The system shall support the formatting and storage of audit logs in such a way as to ensure the integrity of the logs and to support enterprise-level analysis and reporting. Note that the construction of an actual enterprise-level log management mechanism is outside the scope of this document. Mechanisms known to support these goals include but are not limited to the following: 1. Microsoft Windows Event Logs collected by a centralized log management system; 2. Logs in a well-documented format sent via syslog, syslog-ng, or syslog-reliable network protocols to a centralized log management system; 3. Logs stored in an ANSI-SQL database that itself generates audit logs in compliance with the requirements of this document; and 4. Other open logging mechanisms supporting the above requirements including those based on CheckPoint OpSec, ArcSight CEF, and IDMEF. 5. Policy Compliance 11.4 Compliance Measurement The Infosec team will verify compliance to this policy through various methods, including but not limited to, periodic walk-thrus, video monitoring, business tool reports, internal and external audits, and feedback to the policy owner. 11.5 Exceptions Any exception to the policy must be approved by the Infosec team in advance. 11.6 Non-Compliance An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment. 6 7 Related Standards, Policies and Processes None. Definitions and Terms None. 37 | P a g e 8 Revision History Date of Change Responsible Summary of Change By putting in place corporate policies and processes to develop secure baseline builds and manage the configuration and the ongoing functionality of all Information and Communications Technologies (ICT), organisations can greatly improve the security of their ICT systems. Good corporate practice is to develop a strategy to remove or disable unnecessary functionality from ICT systems and keep them patched against known vulnerabilities. Failure to do so is likely to result in increased exposure of the business and its ICT to threats and vulnerabilities and therefore increased risk to the confidentiality, integrity and availability of systems and information7. Identify security requirements for the ICT system or application What is the risk? Establishing and then actively maintaining the secure configuration of ICT systems should be seen as a key security control. ICT systems that are not locked down, hardened or patched will be particularly vulnerable to attacks that may be easily prevented. Organisations that fail to produce and implement corporate security policies that manage the secure configuration and patching of their ICT systems are subject to the following risks: Unauthorised changes to systems An attacker could make unauthorised changes to ICT systems or information, compromising confidentiality, availability and integrity Exploitation of unpatched vulnerabilities New patches are released almost daily and the timely application of security patches is critical to preserving the confidentiality, integrity and availability of ICT systems. 7 Source: UK Government, as at https://www.gov.uk/government/publications/10-steps-to-cyber-securityadvice-sheets/10-steps-secure-configuration--11, as on 9th May, 2017. 38 | P a g e Attackers will attempt to exploit unpatched systems to provide them with unauthorised access to system resources and information. Many successful attacks are enabled by exploiting a vulnerability for which a patch had been issued prior to the attack taking place Exploitation of insecure system configurations An attacker could exploit a system that has not been locked down or hardened by: Gaining unauthorised access to information assets or importing malware Exploiting unnecessary functionality that has not been removed or disabled to conduct attacks and gain unauthorised access to systems, services, resources and information Connecting unauthorised equipment to exfiltrate information or introduce malware Creating a back door to use in the future for malicious purposes Increases in the number of security incidents Without an awareness of vulnerabilities that have been identified and the availability (or not) of patches and fixes, the business will be increasingly disrupted by security incidents Risk management is an increasingly important element of corporate governance and is closely associated with the pursuit of improved business performance, innovation and productivity. The identification, analysis, acceptance and mitigation of risk is essential to the process of buying and implementing new IT products8. By identifying potential risks in advance of undertaking a business activity or business decision, management can determine the likelihood and potential impact of the risks identified, as well as strategies to avert or minimise the threats that each risk poses. Many companies may already have a standing Risk Committee, comprising employees, managers and/or board members, as appropriate. Typically, such a committee would be chaired by the operations manager, a senior executive or a board member, and would regularly meet to review and assess a company’s risk exposures and risk treatment activities. General Risk Management Methodologies Two useful methodologies for managing risks are the ‘Risk Register’ and the ‘Risk Matrix’. The Risk Register is a list of all risks that have been identified, their significance (i.e. whether the risk is likely and how severe its impact will be if it occurs) and whether there is a way of mitigating (reducing) the impact. The headings in a typical Risk Register look something like this: 8 Source: Australian Government, Business, as at https://www.business.gov.au/.../Innovation-Connectionsquick-guide-managing-ICT-r..., as on 9th May, 2017. 39 | P a g e Risk Number e.g. R01 Risk Description Corruption of customer data Likelihood of Occurring (Lo/Med/ Hi) Med Impact if it Occurs (Lo/Med/ Hi) Agreed Risk Mitigation Treatment Residual Risk Rating (Lo/Med/Hi ) Risk Owner Hi Full back up Lo Sales of customer Manager to records, sign off always before reconcile going live. before new Often a company will maintain a general risk register for all system of its activities and periodically report to gosenior managers and board members on the status of theselive. risks. If a company is undertaking a new initiative or project, it will typically create a risk register specifically focused on this new initiative. The important discipline with the risk register is that there is a designated person who is responsible for maintaining it and that there is a regular risk review process during which all active risks are reviewed, to ensure that all risks are being monitored and treated. The Risk Matrix is a visual tool that is very useful for highlighting the key risks confronting any project or business. There are a variety of sophisticated visual presentations, but all employ the same basic concepts. For a small and medium business, the following type of presentation will often be sufficient: Risk Matrix – Residual Risks Following Risk Treatment Business Impact if Risk Occurs High R06 * R12 Medium R02, R09 R10, R11 R08 Low R01, R04, R13, R14, R03, R05, R07 R15, R16, R17, R18, R19, R120, R21, R22, R23 Low High Medium Likelihood of Risk Occurring Legend: Low Risk Medium Risk High Risk * The codes R01, R02 etc. above refer to risk numbers in the relevant Risk Register When using risk management methodologies as illustrated above, it is important to ensure the status 40 | P a g e of risks is regularly monitored by management and that all risks in the Medium to High (orange to red coloured) categories are managed intensively to minimise the business risk they pose if risk mitigation action is not taken. For a more in depth explanation of the broader discipline of risk management, refer to the Australian Standard AS/NZS ISO 31000:2009 Risk Management – Principles and Guidelines. ICT Risks ICT risks are an increasingly important part of corporate risk management, because they include such threats as business interruption, disaster recovery, business and information security, data back-up and protection, software licence compliance, ICT outsourcing and cloud services, and employee and contractor internet and social media use. However, one of the most important and far-reaching areas of ICT risk relates to how new or improved IT products are evaluated, purchased and implemented within a business. This is because new or changed IT systems can have game-changing impacts on a business, potentially affecting many areas. If well thought through, these changes can be extremely positive, creating major business improvements. But careful planning and project management are required, otherwise a new IT system can have major, negative impacts; extending well beyond employees, to customers and suppliers and, ultimately, the viability of the business itself. The Major Types of IT Risk for Business In recent years, a variety of industry surveys of IT risk for business have been conducted across many firms in many industries in a large number of countries. From these types of survey, it is possible to identify four Common themes of IT risks for businesses: 1. Risks caused by falling behind Firms failing to leverage readily available technology to improve business performance, access to markets and competitive position, with the result that they lose ground against competitors and new market entrants. 2. Risks caused by buying without sufficient care: Firms making IT choices that do not fit with their other IT systems (or those of key customers or suppliers), that do not produce the benefits expected and take much longer to implement, or which create unexpected new costs. 3. Risks caused by failing to establish and maintain organisational commitment: 41 | P a g e Firms failing to ensure adequate preparatory training and buy-in by staff, not ensuring strong project alignment and commitment from senior management, and failing to ensure project timelines and new system cut-overs occur as planned. All of which can lead to projects failing to realise anticipated benefits and where legacy systems often continue to run in parallel. 4. Risks caused by missing the opportunity to innovate: Firms not being sufficiently strategic in their IT choices. This is perhaps the greatest risk and can be a consequence of any of the three foregoing risks. Because the opportunity costs of failing to maximise the potential transformative effects of new IT products and solutions can stifle innovation and best-in-class performance. All businesses need to be constantly alert to the potential transformative effects of IT and to adopt systematic processes for evaluating, selecting, buying and implementing IT in just the same way that they would approach any other major, long-term business decision. Identifying and Managing Risks during the IT Product/Service Assessment Stage You should start by asking the following four questions: 1. Do we have a clear idea of our requirements? 2. How have others solved this requirement and what problems have they encountered? 3. Has our initial market research identified solutions with the potential to meet our requirements? 4. Do we have enough information to compare the costs and benefits of potential solutions? One of the best start-points in establishing a sound risk management approach towards IT projects is to review the problem that you are trying to solve or the requirements that you have identified. Often you will need to visit trade shows, conduct internet searches of available solutions and make enquiries of vendors and other businesses with which you interact or of industry associations of which you are a member. The objective is to gain as much understanding of what is available in the market- place and how closely these offerings match your particular requirements. For some businesses, these initial enquiries may be undertaken by one of the owners themselves, in the first instance, or this may be a project that can be allocated to a suitable member of the management team. Either way, it is important, that this early process also involves consultation within the business – especially those whose work area will potentially be affected. Obtaining input to requirements and ensuring the regular review of preliminary findings is a key element in ensuring alignment and buy-in, as well as ensuring that important considerations are not overlooked. 42 | P a g e Depending on the size of the business and the extent of the ICT solution under evaluation, a project team may need to be constituted and specialised external expertise may need to be bought in to augment the process. Once this early ‘scoping’ phase of your potential IT purchase is complete it is important, as part of the process of establishing the ‘business case’, to analyse the findings and the risks that have been identified. Tips: Try listing out potential risks under the following headings: Requirement Risks: e.g. are the requirements documented and agreed by internal stakeholders? Technology Risks: e.g. have the options available and relevant IT trends been adequately researched/validated? Project Management Risks: e.g. is there sufficient capacity to finance and manage the kind of changes envisaged? Project Scheduling Risks: e.g. are there any internal or external factors that impact on when the IT solution can be implemented, and will the changes need to occur in stages? Project Governance Risks: e.g. Are there clear arrangements in place governing accountability for consultation, sign offs and decision-making? Identifying and Managing Risks during the Procurement Phase Once a business has taken a decision to proceed beyond evaluating possible solutions, the serious commitments (and potential risks) commence. It is therefore important to have a clear idea about how ICT procurement works and how to minimise the commercial and business risks involved. ICT procurement typically involves four components: Hardware (such as a computer server or other equipment); Software (such as a new customer relationship management system or accounting system); Implementation services (such as the setting to work of the new hardware, the setting up of the new software, migration of existing data to the new system and staff training); and Ongoing support. Some ICT procurements will involve only one of these categories, but for most ICT procurements all four elements need to be considered collectively. A common procurement risk occurs when a business attempts to purchase these components separately and inadvertently become responsible for system integration. 43 | P a g e Larger businesses will have one or more existing ICT personnel, who can advise on some aspects of procurement, but they will also be busy managing existing IT activities and may not have the time or expertise to manage a significant ICT procurement process. An important first step is therefore determining whether a business has the in-house capacity to manage ICT procurement, or whether specialist assistance will be required. If specialist assistance is required, the business should consult with their other advisors (such as their accountants and/or lawyers) as well as their industry association, before making a decision on who to engage. If using an external advisor, ask for references from other clients who had similar needs and make sure you check with those clients about their experience, before making an appointment. In terms of the risks and risk mitigation strategies that a business should consider when commencing the procurement phase, the following issues are very common potential problems that can be averted if care is taken at the outset. It is important to avoid committing to a single vendor until all of these questions can be answered: General Procurement Risks E.g. how will you decide on a vendor – will you seek quotations? Will you provide vendors with a briefing and an information package? Do you have a draft contract? Have you considered how you will structure payments to ensure that you have control over the vendor’s performance? Will you use your legal or accounting firm to assist with managing elements of the procurement process? What process will you follow to determine a preferred vendor? Vendor-related Risks E.g. Before selecting a preferred vendor, have you checked whether the short-listed vendors have a reputation for successfully meeting requirements similar to yours? Have you spoken with (and even visited) some of the short-listed vendors’ reference sites? Do the vendors have the capacity to be on site and/or respond to calls for assistance when you need them at your location(s)? Are you sure that you understand the structure of each short-listed vendor’s pricing and ongoing support terms. (For example, some vendors will require you to pay an annual software licence fee and if you fail to do so, the software will be deactivated and some cloud service providers may not allow you to transfer your data if you change vendors.) Do each of the short-listed vendors have a detailed implementation schedule and have you walked through it with them to make sure that you agree with their approach and that you can meet any obligations that you have to provide resources, etc.? Have you ensured that the key internal stakeholders have had an opportunity to understand and agree to the preferred vendor’s proposal and to meet the vendor and visit or speak to reference sites, if appropriate? Have you conducted a web search on the short-listed vendors to determine if there are any customer complaints posted on discussion boards and so forth? 44 | P a g e System Compatibility Risks This is a potentially major risk that often only emerges after the procurement decision has been taken. A very good way to avoid this is to have the preferred vendor conduct a small on-site trial to demonstrate how the new system will interface with other business systems. E.g. will the new system interface neatly with all your existing business systems or will there be a need to upgrade or modify those systems so that they can ‘talk’ to the new system. Use this process to identify whether any changes need to be made to network configuration (such as to support more users or to handle multi-site connections), or to adjust on or off-site data storage, back-up or disaster recovery arrangements. Also use this opportunity to assess the adequacy of business change management plans, such as training needed for users of the new system, opportunities to streamline business processes and retire legacy systems. This is also a good way to ensure that the vendor fully understands the requirements of the project. It is important that such a trial is undertaken before any final purchase commitment is given. This will generally ensure that the vendor undertakes the pilot at no charge or for a nominal fee and it provides the business with a valuable opportunity for a pre-purchase reality check. During the past two or three years an increasing range of so-called cloud services has become available. These services are particularly suited to many businesses needs since they essentially outsource many of the traditional hardware and software procurement and maintenance activities to a specialist vendor. For example, many businesses no longer have in-house accounting systems, customer management systems, email systems, switchboards, call centres, secretarial services, and so forth. In the age of the internet, these are all services that can be purchased on a subscription basis and accessed from any location. In considering IT procurement options, it is becoming increasingly important to also consider whether a cloud service offers a viable alternative to an outright purchase. Identifying and Managing Risks during the Implementation Phase If a business conducts its evaluation and procurement phases well, the system implementation phase will be relatively straight-forward. Conversely, deficiencies in evaluation and procurement will surface during implementation and when this does occur, the results can be very painful for all involved. A successful implementation is based on thorough planning, so it is important to ensure that the staff and the vendor have a well-prepared plan at the commencement of the implementation phase. This ‘Implementation Plan’ is often one of the first deliverables for a vendor and can be used as a trigger for their first milestone payment. Important implementation challenges that should be addressed in the implementation plan include: Determining the system testing and acceptance regime - E.g. how will the vendor demonstrate that the system is correctly performing to requirements, before it goes live? 45 | P a g e Depending on the scale of the ICT project, this may entail the initial establishment of a test bed or test environment (on site or at the vendor’s premises), so that the new system can be configured and tested without disruption to business as usual activities. Determining how much configuration of the new system should be undertaken - E.g. If an business is upgrading its accounting system, will it bring across its existing chart of accounts, or adopt a new account structure that is designed to make better use of the new system’s in-built reporting functionality? Planning how (and when) data from existing systems will be migrated to the new system - E.g. Will all of a firm’s customer and vendor data be transferred into the new system, or only customers and vendors from, say, the past two years? If only some data is to be transferred, how will the other data be accessed if required? Tips: An ICT system Implementation Plan should determine: The system testing and acceptance regime How much configuration of the new system should be undertaken Planning how and when data from existing systems will be migrated to the new system System security requirements Training requirements for affected staff Board and senior management issues Go-live and Cut-over arrangements Transitioning to ‘Business as Usual’ and Benefits Realisation System Security requirements - E.g. Ensuring that any new hardware required is installed (either on site or in a hosted environment) and that associated network and data security operates as required. Training for Affected Personnel - E.g. How much training is required, can it be accommodated ‘on the job’ or will staff need to be released for training sessions? How will business disruption be minimised? 46 | P a g e Are staff prepared to undertake disruption? additional hours of work/training to minimise Board and Senior Management Issues - E.g. Are the board and senior management involved in monitoring the project and committed to its implementation? Will there be any impact on the reporting and control processes that they are used to, are they aware of these changes? Go-live and Cut-over Arrangements - E.g. Determining how the business will cut-over to the new system – will it be over a weekend (with sufficient time to roll-back to the old system if there is a problem)? Will there be a staged go-live process, possibly starting at only one site initially and then expanding once the system is known to be working? Will certain key customers or vendors be advised in advance so that any important processing can be completed before the cut-over commences. Will vendor personnel be required on- site during cutover to help with any trouble-shooting? Transitioning to ‘Business as Usual’ and Benefits Realisation - E.g. what is the warranty period for rectification of bugs and deficiencies? How much of the contract value is held back pending final acceptance? Has all training and documentation been delivered? What on-going support arrangements are in place? Often a major ICT investment is partly based on the realisation of savings, such as reduced running costs of legacy systems, productivity improvements or reduced inventories. It is important to press for the realisation of these benefits and to measure the relevant aspects of business performance before and after. Risk Management is designed to enable Businesses to Grow, Innovate and Pursue Opportunities ICT is now one of the major drivers of global productivity and innovation. Businesses need to invest in IT and leverage its game-changing potential. This is particularly the case for small and medium sized businesses, which make up well over 90% of all Australian businesses. Successful businesses have systems and management approaches that are designed to do a better job of managing risk than their competitors. The purpose of this guide to managing risks when buying or implementing new IT systems is to help businesses better understand IT risks, so that they can better manage them. 47 | P a g e How can the risk be managed? Develop corporate policies to update and patch systems Use the latest versions of operating systems, web browsers and applications. Develop and implement corporate policies to ensure that security patches are applied in a timeframe that is commensurate with the organisation’s overall risk management approach. Organisations should use automated patch management and software update tools. Create and maintain hardware and software inventories Create inventories of the authorised hardware and software that constitute ICT systems across the organisation. Ideally, suitably configured automated tools should be used to capture the physical location, the business owner and the purpose of the hardware together with the version and patching status of all software used on the system. The tools should also be used to identify any unauthorised hardware or software, which should be removed. Lock down operating systems and software Consider the balance between system usability and security and then document and implement a secure baseline build for all ICT systems, covering clients, mobile devices, servers, operating systems, applications and network devices such as firewalls and routers. Essentially, any services, functionality or applications that are not required to support the business should be removed or disabled. The secure build profile should be managed by the configuration control and management process and any deviation from the standard build should be documented and formally approved. Conduct regular vulnerability scans Organisations should run automated vulnerability scanning tools against all networked devices regularly and remedy any identified vulnerabilities within an agreed time frame. Organisations should also maintain their situational awareness of the threats and vulnerabilities they face. Establish configuration control and management Produce policies and procedures that define and support the configuration control and change management requirements for all ICT systems, including software. Disable unnecessary input/output devices and removable media access Assess business requirements for user access to input/output devices and removable media (this could include MP3 players and Smart phones). Disable ports and system functionality that is not needed by the business (which may include USB ports, CD/DVD/Card media drives) Implement whitelisting and execution control 48 | P a g e Create and maintain a whitelist of authorised applications and software that can be executed on ICT systems. In addition, ICT systems need to be capable of preventing the installation and execution of unauthorised software and applications by employing process execution controls, software application arbiters and only accepting code that is signed by trusted suppliers; Limit user ability to change configuration Provide users with the minimum system rights and permissions that they need to fulfil their business role. Users with ‘normal’ privileges should be prevented from installing or disabling any software or services running on the system. Activity 2 How can ICT security risk evaluation inform an organisation’s security requirements? 49 | P a g e Activity 2 50 | P a g e How to write an information security policy9 An information security policy is the cornerstone of an information security program. It should reflect the organization's objectives for security and the agreed upon management strategy for securing information. In order to be useful in providing authority to execute the remainder of the information security program, it must also be formally agreed upon by executive management. This means that, in order to compose an information security policy document, an organization has to have well-defined objectives for security and an agreed-upon management strategy for securing information. If there is debate over the content of the policy, then the debate will continue throughout subsequent attempts to enforce it, with the consequence that the information security program itself will be dysfunctional. What to do first There is a plethora of security-policy-in-a-box products on the market, but few of them will be formally agreed upon by executive management without being explained in detail by a security professional. This is not likely to happen due to time constraints inherent in executive management. Even if it was possible to immediately have management endorse an off-the-shelf policy, it is not the right approach to attempt to teach management how to think about security. Rather, the first step in composing a security policy is to find out how management views security. As a security policy is, by definition, a set of management mandates with respect to information security, these mandates provide the marching orders for the security professional. If the security professional instead provides mandates to executive management to sign off on, management requirements are likely to be overlooked. If there is debate over the content of the policy, then the debate will continue throughout subsequent attempts to enforce it, with the consequence that the information security program itself will be dysfunctional. A security professional whose job it is to compose security policy must therefore assume the role of sponge and scribe for executive management. A sponge is a good listener who is able to easily absorb the content of each person's conversation regardless of the group's diversity with respect to communication skills and culture. A scribe documents that content faithfully without embellishment or annotation. A good sponge and scribe will be able to capture common themes from management interviews and prepare a positive statement about how the organization as a whole wants its information protected. The time and effort spent to gain executive consensus on policy will pay off in the authority it lends to the policy enforcement process. Good interview questions that solicit management's opinions on information security are: 9 Source: CSO, as at http://www.csoonline.com/article/2124114/it-strategy/strategic-planning-erm-how-towrite-an-information-security-policy.html, as on 9th May, 2017. 51 | P a g e How would you describe the different types of information you work with? Which types of information do you rely on to make decisions? Are there any information types that are more of a concern to keep private than others? From these questions, an information classification system can be developed (e.g., customer info, financial info, marketing info, etc), and appropriate handling procedures for each can be described at the business process level. Of course, a seasoned security professional will also have advice on how to mold the management opinion with respect to security into a comprehensive organizational strategy. Once it is clear that the security professional completely understands management's opinions, it should be possible to introduce a security framework that is consistent with it. The framework will be the foundation of the organization's Information Security Program, and thus will service as a guide for creating an outline of the information security policy. Creating a framework Often, a security industry standards document is used as the baseline framework. For example, the Security Forum's Standard of Good Practice (www.securityforum.org), the International Standards Organization's Security Management series (27001, 27002, 27005, www.iso.org), and the Information Systems Audit and Control Association's Control Objectives for Information Technology (CoBIT, www.isaca.org). This is a reasonable approach, as it helps to ensure that the policy will be accepted as adequate not only by company management, but also by external auditors and others who may have a stake in the organization's Information Security Program. However, these documents are inherently generic and do not state specific management objectives for security. So they must be combined with management input to produce the policy outline. Moreover, it is not reasonable to expect the management of an organization to change the way the organization is managed in order to comply with a standards document. Rather, the information security professional may learn about good security management practices from these documents, and see if it is possible to incorporate them into the current structure of the target organization. Make it about mandates It is important that security policy always reflect actual practice. Otherwise, the moment the policy is published, the organization is not compliant. It is better to keep policy as a very small set of mandates to which everyone agrees and can comply than to have a very far-reaching policy that few in the organization observe. The information security program can then function to enforce policy compliance while the controversial issues are simultaneously addressed. ... where people are aware that there are no exceptions to policy, they will generally be more willing to assist in getting it right up front Another reason that it is better to keep policy as a very small set of mandates to which everyone agrees is that, where people are aware that there are no exceptions to policy, they will generally be more willing to assist in getting it right up front to ensure that they will be able to comply going forward. 52 | P a g e Once a phrase such as "exceptions to this policy may be made by contacting the executive in charge of...." slips into the policy itself or the program in which it is used, the document becomes completely meaningless. It no longer represents management commitment to an information security program, but instead communicates suspicion that the policy will not be workable. A security professional should consider that if such language were to make its way into a human resources or accounting policy, people could thus be excused from sexual harassment or expense report fraud. A security professional should strive to ensure that information security policy is observed at the same level as other policies enforced within the organization. Policy language should be crafted in such a way that guarantees complete consensus among executive management. For example, suppose there is debate about whether users should have access to removable media such as USB storage devices. A security professional may believe that such access should never be required while a technology executive may believe that technology operations departments responsible for data manipulation must have the ability to move data around on any type of media. At the policy level, the consensus-driven approach would produce a general statement that "all access to removable media devices is approved via a process supported by an accountable executive." The details of the approval processes used by the technology executive can be further negotiated as discussions continue. The general policy statement still prohibits anyone without an accountable executive supporting an approval process from using removable media devices. Employing sub-policies In very large organizations, details on policy compliance alternatives may differ considerably. In these cases, it may be appropriate to segregate policies by intended audience. The organizationwide policy then becomes a global policy, including only the least common denominator of security mandates. Different sub-organizations may then publish their own policies. Such distributed policies are most effective where the audience of sub-policy documents is a well-defined subset of the organization. In this case, the same high level of management commitment need not be sought in order to update these documents. For example, information technology operations policy should require only information technology department head approval as long as it is consistent with the global security policy, and only increases the management commitment to consistent security strategy overall. It would presumably include such directives as "only authorized administrators should be provided access capable of implementing operating system configuration changes" and "passwords for generic IDs should be accessed only in the context of authorized change control processes." Another type of sub-policy may involve people in different departments engaged in some unusual activity that is nevertheless subject to similar security controls, such as outsourcing information processing, or encrypting email communications. The time and effort spent to gain executive consensus on policy will pay off in the authority it lends to the policy enforcement process. On the other hand, subject-specific policies that apply to all users should not be cause to draft new policies, but should be added as sections in the global policy. 53 | P a g e Multiple policies containing organization-wide mandates should be discouraged because multiple policy sources make it more difficult to accomplish a consistent level of security awareness for the any given individual user. It is hard enough to establish policy-awareness programs that reach all in the intended community, without having to clarify why multiple policy documents were created when one would do. For example, new organization-wide restrictions on internet access need not be cause to create a new "internet access" policy. Rather, an "internet access" section can be added to the global security policy. Another caveat for the security professional using the sub-policy approach is to make sure subpolicies do not repeat what is in the global policy, and at the same time are consistent with it. Repetition must be prohibited as it would allow policy documents to get out of sync as they individually evolve. Rather, the sub-documents should refer back to the global document and the two documents should be linked in a manner convenient for the reader. Supplementary documents Even while giving sub-policies due respect, wherever there is an information security directive that can be interpreted in multiple ways without jeopardizing the organization's commitment to information security goals, a security professional should hesitate to include it in any policy. Policy should be reserved for mandates. Alternative implementation strategies can be stated as a responsibility, standard, process, procedure, or guideline. This allows for innovation and flexibility at the department level while still maintaining firm security objectives at the policy level. This does not mean that the associated information protection goals should be removed from the information security program. It just means that not all security strategy can be documented at the policy level of executive mandate. As the information security program matures, the policy can be updated, but policy updates should not be necessary to gain incremental improvements in security. Additional consensus may be continuously improved using other types of Information Security Program documents. Supplementary documents to consider are: Roles and responsibilities — Descriptions of security responsibilities executed by departments other than the security group. For example, technology development departments may be tasked with testing for security vulnerabilities prior to deploying code and human resources departments may be tasked with keeping accurate lists of current employees and contractors. Technology standards — Descriptions of technical configuration parameters and associated values that have been determined to ensure that management can control access to electronic information assets. Process - Workflows demonstrating how security functions performed by different departments combine to ensure secure information-handling. Procedures — Step by step instructions for untrained staff to perform routine security tasks in ways that ensure that the associated preventive, detective, and/or response mechanisms work as planned. 54 | P a g e Guidelines — Advice on the easiest way to comply with security policy, usually written for nontechnical users who have multiple options for secure information-handling processes. What an information security policy includes This leaves the question: what is the minimum information required to be included in an information security policy? It must be at least enough to communicate management aims and direction with respect to security. It should include: 1. Scope — should address all information, systems, facilities, programs, data, networks and all users of technology in the organization, without exception 2. Information classification — should provide content-specific definitions rather than generic "confidential" or "restricted" 3. Management goals — goals for secure handling of information in each classification category (e.g., legal, regulatory, and contractual obligations for security) may be combined and phrased as generic objectives such as "customer privacy entails no authorized cleartext access to customer data for anyone but customer representatives and only for purposes of communicating with customer," "information integrity entails no write access outside accountable job functions," and "prevent loss of assets" 4. Context — Placement of the policy in the context of other management directives and supplementary documents (e.g., is agreed by all at executive level, all other information handling documents must be consistent with it) 5. Supporting documents — include references to supporting documents (e.g., roles and responsibilities, process, technology standards, procedures, guidelines) 6. Specific instructions — include instruction on well-established organization-wide security mandates (e.g., all access to any computer system requires identity verification and authentication, no sharing of individual authentication mechanisms) 7. Responsibilities — outline specific designation of well-established responsibilities (e.g., the technology department is the sole provider of telecommunications lines) 8. Consequences — include consequences for non-compliance (e.g., up to and including dismissal or termination of contract) This list of items will suffice for information security policy completeness with respect to current industry best practice as long as accountability for prescribing specific security measures is established within the "supplementary documents" and "responsibilities" section. While items 6 and 7 may contain a large variety of other agreed-upon details with respect to security measures, it is ok to keep them to a minimum to maintain policy readability and rely on sub-policies or supporting documents to include the requirements. Again, it is more important to have complete compliance at the policy level than to have the policy include a lot of detail. Note that the policy production process itself is something that necessarily exists outside of the policy document. Documentation with respect to policy approvals, updates and version control should also be carefully preserved and available in the event that the policy production process is audited. 55 | P a g e Security in the software development life cycle10 Small changes in the software development life cycle can substantially improve security without breaking the bank or the project schedule. The software development life cycle, or SDLC, encompasses all of the steps that an organization follows when it develops software tools or applications. Organizations that incorporate security in the SDLC benefit from products and applications that are secure by design. Those that fail to involve information security in the life cycle pay the price in the form of costly and disruptive events. In an organization that's been around for several years or more, the SDLC is well-documented and usually includes the steps that are followed and in what order, the business functions and/or individuals responsible for carrying out the steps and information about where records are kept. 10 Source: Tech Target, as at http://searchsecurity.techtarget.com/tip/Security-in-the-software-developmentlife-cycle, as on 9th May, 2017. 56 | P a g e A typical SDLC model contains the following main functions: Conceptual definition. This is a basic description of the new product or program being developed, so that anyone reading it can understand the proposed project. Functional requirements and specifications. This is a list of requirements and specifications from a business function perspective. Technical requirements and specifications. This is a detailed description of technical requirements and specifications in technical terms. Design. This is where the formal detailed design of the product or program is developed. Coding. The actual development of software. Test. This is the formal testing phase. Implementation. This is where the software or product is installed in production. Each major function consists of several tasks, perhaps documented in flowchart notation with inputs, outputs, reports, decisions and approvals. Some companies build workflow applications to support all of this. Getting the right security information to the right people Many people in the entire development process need all kinds of information, including security information, in a form that is useful to them. Here is the type of information that is required during each phase of the SDLC. Conceptual -- Organization information security principles and strategies Functional requirements and specifications -- Information security requirements Technical requirements and specifications -- Information security requirements Design -- Enterprise security architecture and security product standards Coding -- Development standards, practices, libraries and coding examples Testing -- Test plans that show how to verify each security requirement Implementation -- Procedures for integrating existing authentication, access controls, encryption, backup, etc. If you are wondering why maintenance is omitted from the life cycle example here, it is because maintenance is just an iteration of the life cycle: when a change is needed, the entire process starts all over again. All of the validations that are present the first time through the life cycle are needed every time thereafter. Finally, one may say that these changes represent a lot of extra work in a development project. This is not the case – these additions do not present that much extra time. These are but small additions that reap large benefits later on. Approval: Moving to the next step Organizations that use a software development life cycle process usually have approval steps at each major function. This takes the form of some kind of an approval meeting with the right stakeholders present: generally you find managers, directors, occasionally a VP – the people who control budgets, resources and business priorities. 57 | P a g e Someone who represents information security should be present and have the authority to vote at most, if not all, major steps in the life cycle. If someone representing infosec is not present at a life cycle approval meeting, then there is a risk that a project lacking some key security component will be approved, only to become a problem in the future. Fix it now or pay the price later Organizations that fail to involve information security in the life cycle will pay the price in the form of costly and disruptive events. Many bad things can happen to information systems that lack the required security interfaces and characteristics. Some examples include: Orphan user accounts (still-active accounts that belong to employees or contractors who have left the organization) that exist because the information system does not integrate with an organization's identity management or single sign-on solution. Defaced Web sites as a result of systems that were not built to security standards and, therefore, include easily exploited weaknesses. Fraudulent transactions that occur because an application lacked adequate audit trails and/or the processes required to ensure they are examined and issues dealt with. You should figure that problems like these are all costly to solve – in most cases far more costly than the little bit of extra effort required to build the products or applications correctly in the first place. Write an ICT system or application security plan according to the enterprise and ICT system or application security policies All companies should develop and maintain clear and robust policies for safeguarding critical business data and sensitive information, protecting their reputation and discouraging inappropriate behaviour by employees11. Many of these types of policies already exist for “real world” situations, but may need to be tailored to your organization and updated to reflect the increasing impact of cyberspace on everyday transactions, both professional and personal. As with any other business document, cyber security policies should follow good design and governance practices -- not so long that they become unusable, not so vague that they become meaningless, and reviewed on a regular basis to ensure that they stay pertinent as your business needs change. Please note that this document does not address all policy requirements for businesses that fall under legislative acts or directives, such as the Health Insurance Portability and Accountability Act, Sarbanes-Oxley Act or other federal, state or local statutes. 11 Source: Federal Communications Commission, US, as at https://www.dhs.gov/sites/default/files/publications/FCC%20Cybersecurity%20Planning%20Guide_1.pdf, as on 9th May, 2017. 58 | P a g e Cyber Plan Action Items: 1. Establish security roles and responsibilities One of the most effective and least expensive means of preventing serious cyber security incidents is to establish a policy that clearly defines the separation of roles and responsibilities with regard to systems and the information they contain. Many systems are designed to provide for strong RoleBased Access Control (RBAC), but this tool is of little use without well-defined procedures and policies to govern the assignment of roles and their associated constraints. Such policies need to clearly state, at a minimum: • Clearly identify company data ownership and employee roles for security oversight and their inherit privileges, including: o Necessary roles, and the privileges and constraints accorded to those roles. o The types of employees who should be allowed to assume the various roles. o How long an employee may hold a role before access rights must be reviewed. o If employees may hold multiple roles, the circumstances defining when to adopt one role over another. Depending on the types of data regularly handled by your business, it may also make sense to create separate policies governing who is responsible for certain types of data. For example, a business that handles large volumes of personally identifiable information (PII) from its customers may benefit from identifying a chief steward for customers’ privacy information. The steward could serve not only as a subject matter expert on all matters of privacy, but also to serve as the champion for process and technical improvements to PII handling. 2. Establish an employee Internet usage policy The limits on employee Internet usage in the workplace vary widely from business to business. Your guidelines should allow employees the maximum degree of freedom they require to be productive (short breaks to surf the web or perform personal tasks online have been shown to increase productivity). At the same time, rules of behaviour are necessary to ensure that all employees are aware of boundaries, both to keep them safe and to keep your company successful. Some to consider: • Personal breaks to surf the web should be limited to a reasonable amount of time and to certain types of activities. • If you use a web filtering system, employees should have clear knowledge of how and why their web activities will be monitored, and what types of sites are deemed unacceptable by your policy. • Workplace rules of behaviour should be clear, concise and easy to follow. Employees should feel comfortable performing both personal and professional tasks online without making judgment calls as to what may or may not be deemed appropriate. Businesses may want to include a splash warning upon network sign-on that advises the employees of the businesses’ Internet usage policies so that all employees are on notice. 59 | P a g e 3. Establish a social media policy Social networking applications present a number of risks that are difficult to address using technical or procedural solutions. A strong social media policy is crucial for any business that seeks to use social networking to promote its activities and communicate with its customers. At a minimum, a social media policy should clearly include the following: • Specific guidance on when to disclose company activities using social media, and what kinds of details can be discussed in a public forum. • Additional rules of behavior for employees using personal social networking accounts to make clear what kinds of discussion topics or posts could cause risk for the company. • Guidance on the acceptability of using a company email address to register for, or get notices from, social media sites. • Guidance on selecting long and strong passwords for social networking accounts, since very few social media sites enforce strong authentication policies for users. Lastly, all users of social media need to be aware of the risks associated with social networking tools and the types of data that can be automatically disclosed online when using social media. Taking the time to educate your employees on the potential pitfalls of social media use, especially in tandem with geo-location services, may be the most beneficial social networking security practice of all. 4. Identify potential reputation risks All organizations should take the time to identify potential risks to their reputation and develop a strategy to mitigate those risks via policies or other measures as available. Specific types of reputation risks include: • Being impersonated online by a criminal organization (e.g., an illegitimate website spoofing your business name and copying your site design, then attempting to defraud potential customers via phishing scams or other method). • Having sensitive company or customer information leaked to the public via the web. • Having sensitive or inappropriate employee actions made public via the web or social media sites. All businesses should set a policy for managing these types of risks and plans to address such incidents if and when they occur. Such a policy should cover a regular process for identifying potential risks to the company’s reputation in cyberspace, practical measures to prevent those risks from materializing and reference plans to respond and recover from potential incidents as soon as they occur. 60 | P a g e Scams and Fraud New telecommunication technologies may offer countless opportunities for small businesses, but they also offer cyber criminals many new ways to victimize your business, scam your customers and hurt your reputation. Businesses of all sizes should be aware of the most common scams perpetrated online. Cyber Plan Action Items: 1. Train employees to recognize social engineering Social engineering, also known as "pretexting," is used by many criminals, both online and off, to trick unsuspecting people into giving away their personal information and/or installing malicious software onto their computers, devices or networks. Social engineering is successful because the bad guys are doing their best to make their work look and sound legitimate, sometimes even helpful, which makes it easier to deceive users. Most offline social engineering occurs over the telephone, but it frequently occurs online, as well. Information gathered from social networks or posted on websites can be enough to create a convincing ruse to trick your employees. For example, LinkedIn profiles, Facebook posts and Twitter messages can allow a criminal to assemble detailed dossiers on employees. Teaching people the risks involved in sharing personal or business details on the Internet can help you partner with your staff to prevent both personal and organizational losses. Many criminals use social engineering tactics to get individuals to voluntarily install malicious computer software such as fake antivirus, thinking they are doing something that will help make them more secure. Users who are tricked into loading malicious programs on their computers may be providing remote control capabilities to an attacker, unwittingly installing software that can steal financial information or simply try to sell them fake security software. 2. Protect against online fraud Online fraud takes on many guises that can impact everyone, including small businesses and their employees. It is helpful to maintain consistent and predictable online messaging when communicating with your customers to prevent others from impersonating your company. Be sure to never request personal information or account details through email, social networking or other online messages. Let your customers know you will never request this kind of information through such channels and instruct them to contact you directly should they have any concerns. 61 | P a g e 3. Protect against phishing Phishing is the technique used by online criminals to trick people into thinking they are dealing with a trusted website or other entity. Small businesses face this threat from two directions -- phishers may be impersonating them to take advantage of unsuspecting customers, and phishers may be trying to steal their employees’ online credentials. Businesses should ensure that their online communications never ask their customers to submit sensitive information via email. Make a clear statement in your communications reinforcing that you will never ask for personal information via email so that if someone targets your customers, they may realize the request is a scam. Employee awareness is your best defense against your users being tricked into handing over their usernames and passwords to cyber criminals. Explain to everyone that they should never respond to incoming messages requesting private information. Also, to avoid being led to a fake site, they should know to never click on a link sent by email from an untrustworthy source. Employees needing to access a website link sent from a questionable source should open an Internet browser window and manually type in the site’s web address to make sure the emailed link is not maliciously redirecting to a dangerous site. This advice is especially critical for protecting online banking accounts belonging to your organization. Criminals are targeting small business banking accounts more than any other sector. 4. Don’t fall for fake antivirus offers Fake antivirus, "scareware" and other rogue online security scams have been behind some of the most successful online frauds in recent times. Make sure your organization has a policy in place explaining what the procedure is if an employee's computer becomes infected by a virus. Train your employees to recognize a legitimate warning message (using a test file from eicar.org, for example) and to properly notify your IT team if something bad or questionable has happened. If possible, configure your computers to not allow regular users to have administrative access. This will minimize the risk of them installing malicious software and condition users that adding unauthorized software to work computers is against policy. 5. Protect against malware Businesses can experience a compromise through the introduction of malicious software, or malware, that tracks a user’s keyboard strokes, also known as key logging. Many businesses are falling victim to key-logging malware being installed on computer systems in their environment. Once installed, the malware can record keystrokes made on a computer, allowing bad guys to see passwords, credit card numbers and other confidential data. Keeping security software up to date and patching your computers regularly will make it more difficult for this type of malware to infiltrate your network. 62 | P a g e 6. Develop a layered approach to guard against malicious software Despite progress in creating more awareness of security threats on the Internet, malware authors are not giving up. The malware research firm SophosLabs reports seeing more than 100,000 unique malicious software samples every single day. Effective protection against viruses, Trojans and other malicious software requires a layered approach to your defenses. Antivirus software is a must, but should not be a company’s only line of defense. Instead, deploy a combination of many techniques to keep your environment safe. Also, be careful with the use of thumb drives and other removable media. These media could have malicious software pre-installed that can infect your computer, so make sure you trust the source of the removable media devices before you use them. Combining the use of web filtering, antivirus signature protection, proactive malware protection, firewalls, strong security policies and employee training significantly lowers the risk of infection. Keeping protection software up to date along with your operating system and applications increases the safety of your systems. 7. Verify the identity of telephone information seekers Most offline social engineering occurs over the telephone. Information gathered through social networks and information posted on websites can be enough to create a convincing ruse to trick your employees. Ensure that you train employees to never disclose customer information, usernames, passwords or other sensitive details to incoming callers. When someone requests information, always contact the person back using a known phone number or email account to verify the identity and validity of the individual and their request. Network Security Securing your company’s network consists of: (1) identifying all devices and connections on the network; (2) setting boundaries between your company’s systems and others; and (3) enforcing controls to ensure that unauthorized access, misuse, or denial-of-service events can be thwarted or rapidly contained and recovered from if they do occur. Cyber Plan Action Items: 1. Secure internal network and cloud services Your company’s network should be separated from the public Internet by strong user authentication mechanisms and policy enforcement systems such as firewalls and web filtering proxies. Additional monitoring and security solutions, such as anti-virus software and intrusion detection systems, should also be employed to identify and stop malicious code or unauthorized access attempts. Internal network 63 | P a g e After identifying the boundary points on your company’s network, each boundary should be evaluated to determine what types of security controls are necessary and how they can be best deployed. Border routers should be configured to only route traffic to and from your company’s public IP addresses, firewalls should be deployed to restrict traffic only to and from the minimum set of necessary services, and intrusion prevention systems should be configured to monitor for suspicious activity crossing your network perimeter. In order to prevent bottlenecks, all security systems you deploy to your company’s network perimeter should be capable of handling the bandwidth that your carrier provides. Cloud based services Carefully consult your terms of service with all cloud service providers to ensure that your company’s information and activities are protected with the same degree of security you would intend to provide on your own. Request security and auditing from your cloud service providers as applicable to your company’s needs and concerns. Review and understand service level agreements, or SLAs, for system restoration and reconstitution time. You should also inquire about additional services a cloud service can provide. These services may include backupand-restore services and encryption services, which may be very attractive to small businesses. 2. Develop strong password policies Generally speaking, two-factor authentication methods, which require two types of evidence that you are who you claim to be, are safer than using just static passwords for authentication. One common example is a personal security token that displays changing passcodes to be used in conjunction with an established password. However, two-factor systems may not always be possible or practical for your company. Password policies should encourage your employees to employ the strongest passwords possible without creating the need or temptation to reuse passwords or write them down. That means passwords that are random, complex and long (at least 10 characters), that are changed regularly, and that are closely guarded by those who know them. 3. Secure and encrypt your company’s Wi-Fi Wireless access control Your company may choose to operate a Wireless Local Area Network (WLAN) for the use of customers, guests and visitors. If so, it is important that such a WLAN be kept separate from the main company network so that traffic from the public network cannot traverse the company’s internal systems at any point. Internal, non-public WLAN access should be restricted to specific devices and specific users to the greatest extent possible while meeting your company’s business needs. 64 | P a g e Where the internal WLAN has less stringent access controls than your company’s wired network, dual connections -- where a device is able to connect to both the wireless and wired networks simultaneously -- should be prohibited by technical controls on each such capable device (e.g., BIOSlevel LAN/WLAN switch settings). All users should be given unique credentials with preset expiration dates to use when accessing the internal WLAN. Wireless encryption Due to demonstrable security flaws known to exist in older forms of wireless encryption, your company’s internal WLAN should only employ Wi-Fi Protected Access 2 (WPA2) encryption. 4. Encrypt sensitive company data Encryption should be employed to protect any data that your company considers sensitive, in addition to meeting applicable regulatory requirements on information safeguarding. Different encryption schemes are appropriate under different circumstances. However, applications that comply with the OpenPGP standard, such as PGP and GnuPG, provide a wide range of options for securing data on disk as well as in transit. If you choose to offer secure transactions via your company’s website, consult with your service provider about available options for an SSL certificate for your site. 5. Regularly update all applications All systems and software, including networking equipment, should be updated in a timely fashion as patches and firmware upgrades become available. Use automatic updating services whenever possible, especially for security systems such as anti-malware applications, web filtering tools and intrusion prevention systems. 6. Set safe web browsing rules Your company’s internal network should only be able to access those services and resources on the Internet that are essential to the business and the needs of your employees. Use the safe browsing features included with modern web browsing software and a web proxy to ensure that malicious or unauthorized sites cannot be accessed from your internal network. 7. If remote access is enabled, make sure it is secure If your company needs to provide remote access to your company’s internal network over the Internet, one popular and secure option is to employ a secure Virtual Private Network (VPN) system accompanied by strong two-factor authentication, using either hardware or software tokens. Website Security Website security is more important than ever. 65 | P a g e Web servers, which host the data and other content available to your customers on the Internet, are often the most targeted and attacked components of a company’s network. Cyber criminals are constantly looking for improperly secured websites to attack, while many customers say website security is a top consideration when they choose to shop online. As a result, it is essential to secure servers and the network infrastructure that supports them. The consequences of a security breach are great: loss of revenues, damage to credibility, legal liability and loss of customer trust. The following are examples of specific security threats to web servers: • Cyber criminals may exploit software bugs in the web server, underlying operating system, or active content to gain unauthorized access to the web server. Examples of unauthorized access include gaining access to files or folders that were not meant to be publicly accessible and being able to execute commands and/or install malicious software on the web server. • Denial-of-service attacks may be directed at the web server or its supporting network infrastructure to prevent or hinder your website users from making use of its services. • Sensitive information on the web server may be read or modified without authorization. • Sensitive information on backend databases that are used to support interactive elements of a web application may be compromised through the injection of unauthorized software commands. Examples include Structured Query Language (SQL) injection, Lightweight Directory Access Protocol (LDAP) injection and cross-site scripting (XSS). • Sensitive unencrypted information transmitted between the web server and the browser may be intercepted. • Information on the web server may be changed for malicious purposes. Website defacement is a commonly reported example of this threat. • Cyber criminals may gain unauthorized access to resources elsewhere in the organization’s network via a successful attack on the web server. • Cyber criminals may also attack external entities after compromising a web server. These attacks can be launched directly (e.g., from the compromised server against an external server) or indirectly (e.g., placing malicious content on the compromised web server that attempts to exploit vulnerabilities in the web browsers of users visiting the site). • The server may be used as a distribution point for attack tools, pornography or illegally copied software. Cyber Plan Action Items: 1. Carefully plan and address the security aspects of the deployment of a public web server. Because it is much more difficult to address security once deployment and implementation have occurred, security should be considered from the initial planning stage. 66 | P a g e Businesses are more likely to make decisions about configuring computers appropriately and consistently when they develop and use a detailed, well-designed deployment plan. Developing such a plan will support web server administrators in making the inevitable tradeoff decisions between usability, performance and risk. Businesses also need to consider the human resource requirements for the deployment and continued operation of the web server and supporting infrastructure. The following points in a deployment plan: • Types of personnel required -- for example, system and web server administrators, webmasters, network administrators and information systems security personnel. • Skills and training required by assigned personnel. • Individual (i.e., the level of effort required of specific personnel types) and collective staffing (i.e., overall level of effort) requirements. 2. Implement appropriate security management practices and controls when maintaining and operating a secure web server. Appropriate management practices are essential to operating and maintaining a secure web server. Security practices include the identification of your company’s information system assets and the development, documentation and implementation of policies, and guidelines to help ensure the confidentiality, integrity and availability of information system resources. The following practices and controls are recommended: • A business-wide information system security policy. • Server configuration and change control and management. • Risk assessment and management. • Standardized software configurations that satisfy the information system security policy. • Security awareness and training. • Contingency planning, continuity of operations and disaster recovery planning. • Certification and accreditation. 3. Ensure that web server operating systems meet your organization’s security requirements. The first step in securing a web server is securing the underlying operating system. Most commonly available web servers operate on a general-purpose operating system. Many security issues can be avoided if the operating systems underlying web servers are configured appropriately. 67 | P a g e Default hardware and software configurations are typically set by manufacturers to emphasize features, functions and ease of use at the expense of security. Because manufacturers are not aware of each organization’s security needs, each web server administrator must configure new servers to reflect their business’ security requirements and reconfigure them as those requirements change. Using security configuration guides or checklists can assist administrators in securing systems consistently and efficiently. Initially securing an operating system initially generally includes the following steps: • Patch and upgrade the operating system. • Change all default passwords • Remove or disable unnecessary services and applications. • Configure operating system user authentication. • Configure resource controls. • Install and configure additional security controls. • Perform security testing of the operating system. 4. Ensure the web server application meets your organization’s security requirements. In many respects, the secure installation and configuration of the web server application will mirror the operating system process discussed above. The overarching principle is to install the minimal amount of web server services required and eliminate any known vulnerabilities through patches or upgrades. If the installation program installs any unnecessary applications, services or scripts, they should be removed immediately after the installation process concludes. Securing the web server application generally includes the following steps: • Patch and upgrade the web server application. • Remove or disable unnecessary services, applications and sample content. • Configure web server user authentication and access controls. • Configure web server resource controls. • Test the security of the web server application and web content. 5. Ensure that only appropriate content is published on your website. Company websites are often one of the first places cyber criminals search for valuable information. Still, many businesses lack a web publishing process or policy that determines what type of information to publish openly, what information to publish with restricted access and what information should not be published to any publicly accessible repository. Some generally accepted 68 | P a g e examples of what should not be published or at least should be carefully examined and reviewed before being published on a public website include: • Classified or proprietary business information. • Sensitive information relating to your business’ security. • Medical records. • A business’ detailed physical and information security safeguards. • Details about a business’ network and information system infrastructure -- for example, address ranges, naming conventions and access numbers. • Information that specifies or implies physical security vulnerabilities. • Detailed plans, maps, diagrams, aerial photographs and architectural drawings of business buildings, properties or installations. • Any sensitive information about individuals that might be subject to federal, state or, in some instances, international privacy laws. 6. Ensure appropriate steps are taken to protect web content from unauthorized access or modification. Although information available on public websites is intended to be public (assuming a credible review process and policy is in place), it is still important to ensure that information cannot be modified without authorization. Users of such information rely on its integrity even if the information is not confidential. Content on publicly accessible web servers is inherently more vulnerable than information that is inaccessible from the Internet, and this vulnerability means businesses need to protect public web content through the appropriate configuration of web server resource controls. Examples of resource control practices include: • Install or enable only necessary services. • Install web content on a dedicated hard drive or logical partition. • Limit uploads to directories that are not readable by the web server. • Define a single directory for all external scripts or programs executed as part of web content. • Disable the use of hard or symbolic links. • Define a complete web content access matrix identifying which folders and files in the web server document directory are restricted, which are accessible, and by whom. • Disable directory listings. 69 | P a g e • Deploy user authentication to identify approved users, digital signatures and other cryptographic mechanisms as appropriate. • Use intrusion detection systems, intrusion prevention systems and file integrity checkers to spot intrusions and verify web content. • Protect each backend server (i.e., database server or directory server) from command injection attacks. 7. Use active content judiciously after balancing the benefits and risks. Static information resided on the servers of most early websites, typically in the form of text-based documents. Soon thereafter, interactive elements were introduced to offer new opportunities for user interaction. Unfortunately, these same interactive elements introduced new web-related vulnerabilities. They typically involve dynamically executing code using a large number of inputs, from web page URL parameters to hypertext transfer protocol (HTTP) content and, more recently, extensible markup language (XML) content. Different active content technologies pose different related vulnerabilities, and their risks should be weighed against their benefits. Although most websites use some form of active content generators, many also deliver some or all of their content in a static form. 8. Use authentication and cryptographic technologies as appropriate to protect certain types of sensitive data. Public web servers often support technologies for identifying and authenticating users with differing privileges for accessing information. Some of these technologies are based on cryptographic functions that can provide a secure channel between a web browser client and a web server that supports encryption. Web servers may be configured to use different cryptographic algorithms, providing varying levels of security and performance. Without proper user authentication in place, businesses cannot selectively restrict access to specific information. All information that resides on a public web server is then accessible by anyone with access to the server. In addition, without some process to authenticate the server, users of the public web server will not be able to determine whether the server is the “authentic” web server or a counterfeit version operated by a cyber-criminal. Even with an encrypted channel and an authentication mechanism, it is possible that attackers may attempt to access the site by brute force. Improper authentication techniques can allow attackers to gather valid usernames or potentially gain access to the website. Strong authentication mechanisms can also protect against phishing attacks, in which hackers may trick users into providing their personal credentials, and pharming, in which traffic to a legitimate website may be redirected to an illegitimate one. An appropriate level of authentication should be implemented based on the sensitivity of the web server’s users and content. 70 | P a g e 9. Employ network infrastructure to help protect public web servers. The network infrastructure (e.g., firewalls, routers, intrusion detection systems) that supports the web server plays a critical security role. In most configurations, the network infrastructure will be the first line of defense between a public web server and the Internet. Network design alone, though, cannot protect a web server. The frequency, sophistication and variety of web server attacks perpetrated today support the idea that web server security must be implemented through layered and diverse protection mechanisms, an approach sometimes referred to as “defense-indepth.” 10. Commit to an ongoing process of maintaining web server security. Maintaining a secure web server requires constant effort, resources and vigilance. Securely administering a web server on a daily basis is essential. Maintaining the security of a web server will usually involve the following steps: • Configuring, protecting and analyzing log files. • Backing up critical information frequently. • Maintaining a protected authoritative copy of your organization’s web content. • Establishing and following procedures for recovering from compromise. • Testing and applying patches in a timely manner. • Testing security periodically. Email Email has become a critical part of our everyday business, from internal management to direct customer support. The benefits associated with email as a primary business tool far outweigh the negatives. However, businesses must be mindful that a successful email platform starts with basic principles of email security to ensure the privacy and protection of customer and business information. Cyber Plan Action Items: 1. Set up a spam email filter It has been well documented that spam, phishing attempts and otherwise unsolicited and unwelcome email often accounts for more than 60 percent of all email that an individual or business receives. Email is the primary method for spreading viruses and malware and it is one of the easiest to defend against. Consider using email-filtering services that your email service, hosting provider or other cloud providers offer. 71 | P a g e A local email filter application is also an important component of a solid antivirus strategy. Ensure that automatic updates are enabled on your email application, email filter and anti-virus programs. Ensure that filters are reviewed regularly so that important email and/or domains are not blocked in error. 2. Train your employees in responsible email usage The last line of defense for all of your cyber risk efforts lies with the employees who use tools such as email and their responsible and appropriate use and management of the information under their control. Technology alone cannot make a business secure. Employees must be trained to identify risks associated with email use, how and when to use email appropriate to their work, and when to seek assistance of professionals. Employee awareness training is available in many forms, including printed media, videos and online training. Consider requiring security awareness training for all new employees and refresher courses every year. Simple efforts such as monthly newsletters, urgent bulletins when new viruses are detected, and even posters in common areas to remind your employees of key security and privacy to-do’s create a work environment that is educated in protecting your business. 3. Protect sensitive information sent via email With its proliferation as a primary tool to communicate internally and externally, business email often includes sensitive information. Whether it is company information that could harm your business or regulated data such as personal health information (PHI) or personally identifiable information (PII), it is important to ensure that such information is only sent and accessed by those who are entitled to see it. Since email in its native form is not designed to be secure, incidents of misaddressing or other common accidental forwarding can lead to data leakage. Businesses that handle this type of information should consider whether such information should be sent via email, or at least consider using email encryption. Encryption is the process of converting data into unreadable format to prevent disclosure to unauthorized personnel. Only individuals or organizations with access to the encryption key can read the information. Other cloud services offer “Secure Web Enabled Drop Boxes” that enable secure data transfer for sensitive information, which is often a better approach to transmitting between companies or customers. 4. Set a sensible email retention policy Another important consideration is the management of email that resides on company messaging systems and your users’ computers. From the cost of storage and backup to legal and regulatory requirements, companies should document how they will handle email retention and implement basic controls to help them attain those standards. 72 | P a g e Many industries have specific rules that dictate how long emails can or should be retained, but the basic rule of thumb is only as long as it supports your business efforts. Many companies implement a 60-90 day retention standard if not compelled by law to another retention period. To ensure compliance, companies should consider mandatory archiving at a chosen retention cycle end date and automatic permanent email removal after another set point, such as180-360 days in archives. In addition, organizations should discourage the use of personal folders on employee computers (most often configurable from the e-mail system level), as this will make it more difficult to manage company standards. 5. Develop an email usage policy Policies are important for setting expectations with your employees or users, and for developing standards to ensure adherence to your published polices. Your policies should be easy to read, understand, define and enforce. Key areas to address include what the company email system should and should not be used for, and what data are allowed to be transmitted. Other policy areas should address retention, privacy and acceptable use. Depending on your business and jurisdiction, you may have a need for email monitoring. The rights of the business and the user should be documented in the policy as well. The policy should be part of your general end user awareness training and reviewed for updates on a yearly basis. Mobile Devices If your company uses mobile devices to conduct company business, such as accessing company email or sensitive data, pay close attention to mobile security and the potential threats that can expose and compromise your overall business networks. This section describes the mobile threat environment and the practices that small businesses can use to help secure devices such as smartphones, tablets and Wi-Fi enabled laptops. Many organizations are finding that employees are most productive when using mobile devices, and the benefits are too great to ignore. But while mobility can increase workplace productivity, allowing employees to bring their own mobile devices into the enterprise can create significant security and management challenges. Data loss and data breaches caused by lost or stolen phones create big challenges, as mobile devices are now used to store confidential business information and access the corporate network. According to a December 2010 Symantec mobile security survey, 68 percent of respondents ranked loss or theft as their top mobile-device security concern, while 56 percent said mobile malware is their number two concern. It is important to remember that while the individual employee may be liable for a device, the company is still liable for the data. Top threats targeting mobile devices 73 | P a g e • Data Loss – An employee or hacker accesses sensitive information from device or network. This can be unintentional or malicious, and is considered the biggest threat to mobile devices • Social Engineering Attacks – A cybercriminal attempts to trick users to disclose sensitive information or install malware. Methods include phishing and targeted attacks. • Malware – Malicious software that includes traditional computer viruses, computer worms and Trojan horse programs. Specific examples include the Ikee worm, targeting iOS-based devices; and Pjapps malware that can enroll infected Android devices in a collection of hacker-controlled “zombie” devices known as a “botnet.” • Data Integrity Threats – Attempts to corrupt or modify data in order to disrupt operations of a business for financial gain. These can also occur unintentionally. • Resource Abuse – Attempts to misuse network, device or identity resources. Examples include sending spam from compromised devices or denial of service attacks using computing resources of compromised devices. • Web and Network-based Attacks – Launched by malicious websites or compromised legitimate sites, these target a device’s browser and attempt to install malware or steal confidential data that flows through it. Cyber Plan Action Items: A few simple steps can to help ensure company information is protected. These include requiring all mobile devices that connect to the business network be equipped with security software and password protection; and providing general security training to make employees aware of the importance of security practices for mobile devices. More specific practices are detailed below. 1. Use security software on all smartphones Security software specifically designed for smartphones can stop hackers and prevent cyber criminals from stealing your information or spying on you when you use public networks. threats before they cause you problems. It can also eliminate annoying text and multimedia spam messages. It can detect and remove viruses and other mobile 2. Make sure all software is up to date Mobile devices must be treated like personal computers in that all software on the devices should be kept current, especially the security software. This will protect devices from new variants of malware and viruses that threaten your company’s critical information. 3. Encrypt the data on mobile devices 74 | P a g e Business and personal information stored on mobile devices is often sensitive. Encrypting this data is another must. If a device is lost and the SIM card stolen, the thief will not be able to access the data if the proper encryption technology is loaded on the device. 4. Have users password protect access to mobile devices In addition to encryption and security updates, it is important to use strong passwords to protect data stored on mobile devices. This will go a long way toward keeping a thief from accessing sensitive data if the device is lost or hacked. 5. Urge users to be aware of their surroundings Whether entering passwords or viewing sensitive or confidential data, users should be cautious of who might be looking over their shoulder. 6. Employ these strategies for email, texting and social networking Avoid opening unexpected text messages from unknown senders – As with email, attackers can use text messages to spread malware, phishing scams and other threats among mobile device users. The same caution should be applied to opening unsolicited text messages that users have become accustomed to with email. Don’t be lured in by spammers and phishers – To shield business networks from cyber criminals, small businesses should deploy appropriate email security solutions, including spam prevention, which protect a company’s reputation and manage risks. Click with caution – Just like on stationary PCs, social networking on mobile devices and laptops should be conducted with care and caution. Users should not open unidentified links, chat with unknown people or visit unfamiliar sites. it. 7. Set reporting procedures for lost or stolen equipment In the case of a loss or theft, employees and management should all know what to do next. Processes to deactivate the device and protect its information from intrusion should be in place. Products are also available for the automation of such processes, allowing small businesses to breathe easier after such incidents. 8. Ensure all devices are wiped clean prior to disposal Most mobile devices have a reset function that allows all data to be wiped. SIM cards should also be removed and destroyed. It doesn’t take much for a user to be tricked into compromising a device and the information on 75 | P a g e Employees Businesses must establish formal recruitment and employment processes to control and preserve the quality of their employees. Many employers have learned the hard way that hiring someone with a criminal record, falsified credentials or undesirable background can create a legal and financial nightmare. Without exercising due diligence in hiring, employers run the risk of making unwise hiring choices that can lead to workplace violence, theft, embezzlement, lawsuits for negligent hiring and numerous other workplace problems. Cyber Plan Action Items: 1. Develop a hiring process that properly vets candidates The hiring process should be a collaborative effort among different groups of your organization, including recruitment, human resources, security, legal and management teams. It is important to have a solid application, resume, interview and reference-checking process to identify potential gaps and issues that may appear in a background check. An online employment screening resource called the “Online Safe Hiring Certification Course” can help you set the groundwork for a safe recruitment process. The course will teach your teams what to look for in the different stages of the hiring process, how to interview and how to set up a safe hiring program to avoid hiring an employee that may be problematic. The course is available here: http://www.esrcheck.com/ESRonlineSafeHiringCourse.php. 2. Perform background checks and credentialing 76 | P a g e Background checks are essential and must be consistent. Using a background screening company is highly recommended. The standard background screening should include the following checks: • Employment verification • Education verification • Criminal records • Drug testing • The U.S. Treasury Office of Foreign Affairs and Control • Sex offender registries • Social Security traces and validation Depending on the type of your business, other screening criteria may consist of credit check, civil checks and federal criminal checks. Conducting post-hire checks for all employees every two to three years, depending on your industry, is also recommended. If you do conduct background checks, you as an employer have obligations under the Fair Credit Reporting Act. For more information about employer obligations under the FCRA, visit http://business.ftc.gov/documents/bus08using-consumer-reports-what-employers-need-know. 3. Take care in dealing with third parties Employers should properly vet partner companies through which your organization hires third-party consultants. To ensure consistent screening criteria are enforced for third-party consultants, you need to explicitly set the credentialing requirements in your service 4. Set appropriate access controls for employees Both client data and internal company data are considered confidential and need particular care when viewed, stored, used, transmitted or disposed. It is important to analyze the role of each employee and set data access control based upon the role. If a role does not require the employee to ever use sensitive data, the employee’s access to the data should be strictly prohibited. However, if the role requires the employee to work with sensitive data, the level of access must be analyzed thoroughly and be assigned in a controlled and tiered manner following “least-privilege” principles, which allow the employee to only access data that is necessary to perform his or her job. If the organization does not have a system in place to control data access, the following precautions are strongly recommended. Every employee should: 77 | P a g e • Never access or view client data without a valid business reason. Access should be on a need-toknow basis. • Never provide confidential data to anyone – client representatives, business partners or even other employees – unless you are sure of the identity and authority of that person. • Never use client data for development, testing, training presentations or any purpose other than providing production service, client-specific testing or production diagnostics. Only properly sanitized data that cannot be traced to a client, client employee, customer or your organization’s employee should be used for such purposes. • Always use secure transmission methods such as secure email, secure file transfer (from application to application) and encrypted electronic media (e.g., CDs, USB drives or tapes). • Always keep confidential data (hard copy and electronic) only as long as it is needed. • Follow a “clean desk” policy, keeping workspaces uncluttered and securing sensitive documents so that confidential information does not get into the wrong hands. • Always use only approved document disposal services or shred all hardcopy documents containing confidential information when finished using them. Similarly, use only approved methods that fully remove all data when disposing of, sending out for repair or preparing to reuse electronic media. 5. Provide security training for employees Security awareness training teaches employees to understand system vulnerabilities and threats to business operations that are present when using a computer on a business network. A strong IT security program must include training IT users on security policy, procedures and techniques, as well as the various management, operational and technical controls necessary and available to keep IT resources secure. In addition, IT infrastructure managers must have the skills necessary to carry out their assigned duties effectively. Failure to give attention to the area of security training puts an enterprise at great risk because security of business resources is as much a human issue as it is a technology issue. Technology users are the largest audience in any organization and are the single most important group of people who can help to reduce unintentional errors and IT vulnerabilities. Users may include employees, contractors, foreign or domestic guest researchers, other personnel, visitors, guests and other collaborators or associates requiring access. Users must: • Understand and comply with security policies and procedures. • Be appropriately trained in the rules of behavior for the systems and applications to which they have access. • Work with management to meet training needs. 78 | P a g e • Keep software and applications updated with security patches. • Be aware of actions they can take to better protect company information. These actions include: proper password usage, data backup, proper antivirus protection, reporting any suspected incidents or violations of security policy, and following rules established to avoid social engineering attacks and deter the spread of spam or viruses and worms. A clear categorization of what is considered sensitive data versus non-sensitive data is also needed. Typically, the following data are considered sensitive information that should be handled with precaution: • Government issued identification numbers (e.g., Social Security numbers, driver’s license numbers) • Financial account information (bank account numbers, credit card numbers) • Medical records • Health insurance information • Salary information • Passwords The training should cover security policies for all means of access and transmission methods, including secure databases, email, file transfer, encrypted electronic media and hard copies. Employers should constantly emphasize the critical nature of data security. Regularly scheduled refresher training courses should be established in order to instill the data security culture of your organization. Additionally, distribute data privacy and security related news articles in your training, and send organization-wide communication on notable data privacy related news as reminders to your employees. Facility Security Protecting employees and members of the public who visit your facility is a complex and challenging responsibility. It’s also one of your company’s top priorities. Cyber Plan Action Items: 1. Recognize the importance of securing your company facilities The physical security of a facility depends on a number of security decisions that can be identified through a comprehensive risk-management process. The objective of risk management is to identify an achievable level of protection for your company that corresponds as closely as possible to the level of risk without exceeding the risk. It is easy to think about physical security of your company’s facility as merely an exercise in maintaining control of access points and ensuring there is complete visibility in areas that are determined to be of high-risk – either because of the threat of easy public access or because of the value of information located nearby. However, maintaining security of your company’s facility also includes the physical environment of public spaces. For instance: 79 | P a g e • Employees whose computers have access to sensitive information should not have their computer monitors oriented toward publicly accessible spaces such as reception areas, check-in desks and waiting rooms. • Employees should be trained to not write out logins and passwords on small pieces of paper affixed to computer equipment viewable in public spaces. • Easy-to-grab equipment that could contain sensitive or personally identifiable information – such as laptops, electronic tablets and cell phones – should be located away from public areas. If you have an environment where employees are working in a waiting room or reception area, train them to not leave these types of devices out on their desks unsecured. • Consider implementing a badge identification system for all employees, and train employees to stop and question anyone in the operational business area without a badge or who appears to be an unescorted visitor. 2. Minimize and safeguard printed materials with sensitive information Probably the most effective way to minimize the risk of losing control of sensitive information from printed materials is to minimize the amount of printed materials that contain sensitive information. Management procedures should limit how many instances and copies of printed reports memoranda and other material containing personally identifiable information exist. Safeguard copies of material containing sensitive information by providing employees with locking file cabinets or safes. Make it a standard operating procedure to lock up important information. Train employees to understand that simply leaving the wrong printed material on a desk, in view of the general public, can result in consequences that impact the entire company and your customers. 3. Ensure mail security Your mail center can introduce a wide range of potential threats to your business. Your center’s screening and handling processes must be able to identify threats and hoaxes and eliminate or mitigate the risk they pose to facilities, employees and daily operations. Your company should ensure that mail managers understand the range of screening procedures and evaluate them in terms of your specific operational requirements. 4. Dispose of trash securely Too often, sensitive information – including customers’ personally identifiable information, business financial and other data, and company system access information – is available for anyone to find in the trash. Invest in businessgrade shredders and buy enough of them to make it convenient for employees. Alternatively, subscribe to a trusted shredding company that will provide locked containers for storage until documents are shredded. Develop standard procedures and employee training programs to ensure that everyone in your company is aware of what types of information need to be shredded. 80 | P a g e 5. Dispose electronic equipment securely Be aware that emptying the recycle bin on your desktop or deleting documents from folders on your computer or other electronic device may not delete information forever. Those with advanced computer skills can still access your information even after you think you’ve destroyed it. Disposing of electronic equipment requires skilled specialists in order to ensure the security of sensitive information contained within that equipment. If outside help, such as an experienced electronic equipment recycler and data security vendor, is not available or too expensive, you should at a minimum remove computer hard drives and have them shredded. Also, be mindful of risks with other types of equipment associated with computer equipment, including CDs and thumb drives. 6. Train your employees in facility security procedures A security breach of customer information or a breach of internal company information can result in a public loss of confidence in your company and can be as devastating for your business as a natural disaster. In order to address such risks, you must devote your time, attention and resources (including employee training time) to the potential vulnerabilities in your business environment and the procedures and practices that must be a standard part of each employee’s workday. And while formal training is important to maintaining security, the daily procedures you establish in both the normal conduct of business and in the way you model good security behaviours and practices are equally important. In short, security training should be stressed as critical and reinforced via daily procedures and leadership modelling. Operational Security While operational security, or OPSEC, has its origins in securing information important to military operations, it has applications across the business community today. In a commercial context, OPSEC is the process of denying hackers access to any information about the capabilities or intentions of a business by identifying, controlling and protecting evidence of the planning and execution of activities that are essential the success of operations. OPSEC is a continuous process that consists of five distinct actions: • Identify information that is critical to your business. • Analyze the threat to that critical information. • Analyze the vulnerabilities to your business that would allow a cyber-criminal to access critical information. • Assess the risk to your business if the vulnerabilities are exploited. • Apply countermeasures to mitigate the risk factors. 81 | P a g e In addition to being a five-step process, OPSEC is also a mindset that all business employees should embrace. By educating oneself on OPSEC risks and methodologies, protecting sensitive information that is critical to the success of your business becomes second nature. This section explains the OPSEC process and provides some general guidelines that are applicable to most businesses. An understanding of the following terms is required before the process can be explained: • Critical information – Specific data about your business strategies and operations that are needed by cyber criminals to hamper or harm your business from successfully operating. • OPSEC indicators – Business operations and publicly available information that can be interpreted or pieced together by a cyber-criminal to derive critical information. • OPSEC vulnerability – A condition in which business operations provide OPSEC indicators that may be obtained and accurately evaluated by a cyber-criminal to provide a basis for hampering or harming successful business operations. Cyber Plan Action Items: 1. Identity of critical information The identification of critical information is important in that it focuses the remainder of the OPSEC process on protecting vital information rather than attempting to protect all information relevant to business operations. Given that any business has limited time, personnel and money for developing secure business practices, it is essential to focus those limited resources on protecting information that is most critical to successful business operations. Examples of critical information include, but should not be limited to, the following: • Customer lists and contact information • Contracts • Patents and intellectual property • Leases and deeds • Policy manuals • Articles of incorporation • Corporate papers • Laboratory notebooks • Audio tapes 82 | P a g e • Video tapes • Photographs and slides • Strategic plans and board meeting minutes Importantly, what is critical information for one business may not be critical for another business. Use your company’s mission as a guide for determining what data are truly vital. 2. Analyze threats This action involves research and analysis to identify likely cyber criminals who may attempt to obtain critical information regarding your company’s operations. OPSEC planners in your business should answer the following critical information questions: • Who might be a cyber-criminal (e.g. competitors, politically motivated hackers, etc.)? • What are cyber criminal’s goals? • What actions might the cybercriminal take? • What critical information does the cybercriminal already have on your company’s operations? (i.e., what is already publicly available?) 3. Analyze vulnerabilities The purpose of this action is to identify the vulnerabilities of your business in protecting critical information. It requires examining each aspect of security that seeks to protect your critical information and then comparing those indicators with the threats identified in the previous step. Common vulnerabilities for small businesses include the following: • Poorly secured mobile devices that have access to critical information. • Lack of policy on what information and networked equipment can be taken home from work or taken abroad on travel. • Storage of critical information on personal email accounts or other non-company networks. • Lack of policy on what business information can be posted to or accessed by social network sites. 4. Assess risk This action has two components. First, OPSEC managers must analyze the vulnerabilities identified in the previous action and identify possible OPSEC measures to mitigate each one. Second, specific OPSEC measures must be selected for execution based upon a risk assessment done by your company’s senior leadership. Risk assessment requires comparing the estimated cost associated with implementing each possible OPSEC measure to the potential harmful effects on business operations resulting from the exploitation of a particular vulnerability. 83 | P a g e OPSEC measures may entail some cost in time, resources, personnel or interference with normal operations. If the cost to achieve OPSEC protection exceeds the cost of the harm that an intruder could inflict, then the application of the measure is inappropriate. Because the decision not to implement a particular OPSEC measure entails risks, this step requires your company’s leadership approval. 5. Apply appropriate OPSEC measures In this action, your company’s leadership reviews and implements the OPSEC measures selected in the assessment of risk action. Before OPSEC measures can be selected, security objectives and critical information must be known, indicators identified and vulnerabilities assessed. Payment Cards If your business accepts payment by credit or debit cards, it is important to have security steps in place to ensure your customer information is safe. You also may have security obligations pursuant to agreements with your bank or payment services processor. These entities can help you prevent fraud. In addition, free resources and general security tips are available to learn how to keep sensitive information – beyond payment information – safe. Cyber Plan Action Items: 1. Understand and catalog customer and card data you keep • Make a list of the type of customer and card information you collect and keep – names, addresses, identification information, payment card numbers, magnetic stripe data, bank account details and Social Security numbers. It’s not only card numbers criminals want; they’re looking for all types of personal information, especially if it helps them commit identity fraud; • Understand where you keep such information and how it is protected. • Determine who has access to this data and if they need to have access. 2. Evaluate whether you need to keep all the data you store • Once you know what information you collect and store, evaluate whether you really need to keep it. Often businesses may not realize they’re logging or otherwise keeping unnecessary data until they conduct an audit. Not keeping sensitive data in storage makes it harder for criminals to steal it; • If you’ve been using card numbers for purposes other than payment transactions, such as a customer loyalty program, ask your merchant processor if you can use alternative data instead. 84 | P a g e Tokenization, for example, is technology that masks card numbers and replaces it with an alternate number that can’t be used for fraud. 3. Use secure tools and services • The payments industry maintains lists of hardware, software and service providers who have been validated against industry security requirements; • Small businesses that use integrated payment systems, in which the card terminal is connected to a larger computer system, can check the list of validated payment applications to make sure any software they employ has been tested; • Have a conversation about security with your provider if the products or services you are currently using are not on the lists. 4. Control access to payment systems • Whether you use a more complicated payment system or a simple standalone terminal, make sure you carefully control access. • Isolate payment systems from other, less secure programs, especially those connected to the Internet. For example, don’t use the same computer to process payments and surf the Internet. • Control or limit access to payment systems to only employees who need access. • Make sure you use a secure system for remote access or eliminate remote access if you don’t need it so that criminals cannot infiltrate your system from the Internet. 5. Use security tools and resources Work with your bank or processor and ask about the anti-fraud measures, tools and services you can use to ensure criminals cannot use stolen card information at your business. • For e-commerce retailers: - The CVV2 code is the three-digit number on the signature panel that can help verify that the customer has physical possession of the card and not just the account number. - Retailers can also use Address Verification Service to ensure the cardholder has provided the correct billing address associated with the account. - Services such as Verified by Visa prompt the cardholder to enter a personal password confirming their identity and providing an extra layer of protection. • For brick and mortar retailers: - Swipe the card and get an electronic authorization for the transaction. - Check that the signature matches the card. - Ensure your payment terminal is secure and safe from tampering. 85 | P a g e 6. Remember the security basics • Use strong, unique passwords and change them frequently. • Use up-to-date firewall and anti-virus technologies. • Do not click on suspicious links you may receive by email or encounter online. Sample Agency Security Plan Template12 1. Introduction Outlines the importance of the plan and its relationship with the agencies Security Policy and culture. 2. Scope This section should outline the areas of the organisation that the Plan applies to – for example is it a plan for the whole agency or only specific portfolios or work units. 3. Purpose and Objectives This section should provide clear and concise statements about what the Security Plan is designed to achieve and outline the relationship between agency security policies and processes and the corporate plans and business objectives. 4. Current Security Environment This provides a summary and analysis of the agency risk assessment highlighting the current threats and vulnerabilities along with an assessment of current security environment and treatments in place. 5. Security strategies and actions This section should outline security strategies and recommended controls which need to be implemented or maintained to achieve the desired level of agency security and a description of how this is to be achieved and who is responsible. 6. Residual Risks By definition, the residual risk is the risks that remain after all possible (cost-effective) mitigation or treatment of risks. It is important that the plan estimate, describe and rate these risks to guide the priorities for ongoing monitoring of risks. 12 Source: Queensland Government, Chief Information Office, as at https://www.qgcio.qld.gov.au/products/qgea-documents/549-information-security/2422-security-planexample-1-is18-toolbox, as on 9th May, 2017. 86 | P a g e 7. Implementation Schedule This section should provide an indication of timeframes and the key milestones in the implementation of risk treatments and actions. 8. Resources This section should detail the resources and cost requirements for implementing the recommendations outlined in the earlier section on Strategies and Actions. 9. Review Outline the timing and process for review of the plan. An attempt to distill the often overwhelming amount of security policy information into a few concise ideas13. by eminent security authors Cyrus Peikari and Seth Fogie. But Cyrus and Seth realize that there is a lot of information out there on policy making. In this short article, provided by InformIT, they attempt to distill the often overwhelming amount of information into a few concise ideas. Security policies are part of any well-maintained information system. There are numerous guides and templates available that seem to provide you with a reference for creating the perfect security policy. However, to the dismay of many administrators and IT managers, a good security policy is not a simple plug-and-play component. For a policy to show any return on investment, it must become integrated into the processes and procedures of a business, along with the support of the people who are expected to follow it. Without this type of attention and support, a security policy will be worthless. Security policy design often requires weeks of testing, meetings and data analysis. These next few pages will provide an overview of the obstacles that must be overcome in order to create the perfect security policy. Due to the enormous amount of information available, we have attempted to consolidate this subject into one brief section. Defining the security policy Over the years, there have been many attempts to define the term "security policy." There are numerous books, articles and Web sites that deal with nothing but security policies. As a result, there is a lot of data available to assist the policy maker, which unfortunately often has the effect of overwhelming them. For this reason, we will look at two popular variations of a security policy definition. 13 Source: Tech Target, as at http://searchsecurity.techtarget.com/tip/Writing-a-security-policy, as on 9th May, 2017. 87 | P a g e The first is provided by The SANS Institute, which starts by defining a policy as "a document that outlines specific requirements or rules that must be met...usually point-specific, covering a single area." In other words, SANS describes a security policy as a modular method for defining and ultimately developing specific guidelines or rule sets that are used to control individual aspects of a computer system, such as acceptable use, password creation or instant messaging use. Depending on the level of security required, a company can create a few general policies that lump together multiple areas of security, or they can create very specific itemized policies that uniquely define each threat and then create a policy to handle that threat. The level should depend upon the value of the assets at risk and the required level of security needed to contain the threat. The second definition uses a more global summary. This definition is taken from an article written by Ed Tittel in which he references SearchSecurity.com: "In business, a security policy is a document that states in writing how a company plans to protect the company's physical and information technology (IT) assets." This definition highlights the purpose of the security policy verses the method of meeting this goal. However, if you merge the two definitions, a security policy can be defined as a set of documents that describes the security goals as required for the sole purpose of protecting the physical and information assets of a business. Based on this, there are many subdefinitions that can be drawn from this overview of such a complex issue. The following will break down the security policy's purpose and how it can actually protect your company's assets. Document The security policy will take the form of a document or a collection of documents depending on your intent. From the initial assessment to the final maintenance plan, each item, standard, guideline and procedure should be listed in a policy. This not only provides future policy creators with a guide to create standards and guidelines, but it also helps the IT administrators develop their personal and explicit instructions to help them meet the business goals of the policy. In addition, the policy can also become a point of reference in case a violation occurs that results in a dismissal or other penalty. You can expect this document to be rather long and extensive. Security goals First, a policy itself includes no explicit procedures to meet its own goal. This is the job of IT administrators. However, it should be noted that the procedures should end up as part of the overall security policy document. Instead, the policy is a "...high-level [plan] that describe the goals of the procedures. Policies are not guidelines or standards, nor are they procedures or controls. Policies describe security in general terms, not specifics. They provide the blueprints for an overall security program just as a specification defines your next product." From this short excerpt of CISSP Security Management and Practices by Roberta Bragg, you can clearly see what the security policy should contain. 88 | P a g e In addition to the general layout of a policy, there are some indirect goals that every security policy should meet. As TICSA Certification: Information Security Basics describes, "...any good security policy must address the following concerns: Prevent waste or inappropriate use of organization resources (especially computing resources). Limit or eliminate potential legal liability, be it from employees or third parties. Preserve and protect valuable, confidential or proprietary information from unauthorized access or disclosure." Protecting The goals outlined in the security policy ultimately are to protect an asset. While it is important to determine what that asset is (discussed next), you also need to determine what you are protecting against. In other words, are you concerned about corporate espionage, theft of intellectual property, intrusion and destruction of files from external hackers or all of the above? Determining what you are protecting against is an important part of a security policy and needs to be determined early on in the creation. On the flip side, protection also involves defining where and how consequences are to be administered in the case there is a violation. While the specifics of the rebuttals can be left to department heads, the basic security policy needs to define the methods by which protection can be enforced. Are authorities to be contacted? Will violations be handled in house? What are the levels of threat? These questions and more need to be answered. Assets While the other sections are important, the value of the security policy is ultimately related to the assets it is protecting. As a result, a company must perform an in-depth audit of their resources to determine what constitutes as an asset and more importantly, the value of that asset. This can be one of the most challenging parts of developing any security policy due to the fact that many items are hard to put a price tag on, and others are hard to define. For example, it is easy to put a price tag on a laptop, at least the physical value. However, how can you determine the value of the software, programs, e-mails and other pieces of information on the drive? Not only do they have an immediate value due to their contents, but there is also a hidden cost if another company were to discover or steal any sensitive information. Summary of security policies At this point you can see how complex a security policy can be. A good security policy cannot simply be haphazardly thrown together. In "Developing a Security Policy", written by Sun Microsystems, the characteristics of a good security policy are defined as: They must be implementable through system administration procedures, publishing of acceptable use guidelines or other appropriate methods. They must be enforceable with security tools, where appropriate, and with sanctions, where actual prevention is not technically feasible. 89 | P a g e They must clearly define the areas of responsibility for the users, administrators and management. They must be documented, distributed and communicated. So, from this you can see that a policy must be more than a big document. If no one can understand it or use it, the time and effort put into it will be wasted. The following section will provide you with an example of a simple e-mail policy, along with a discussion explaining the reason for each point. Activity 3 What should be included in a security policy and how is this different from a security plan? 90 | P a g e Activity 3 91 | P a g e Crafting a Technology Security Plan14 Most small-business owners understand that complete, end-to-end network security is something they should have--but it's something they probably don't. And how can they? With security threats coming from a multitude of sources and no end in sight to the new attacks that are frequently launched on both networks and PCs, keeping up with all these threats and figuring out just what to do about them is challenging enough for big companies with dedicated IT staffs. For small businesses, it can be completely overwhelming. The risks of not adequately securing your business network and PCs are huge, however. Remember: It's not just your data that's at risk from attacks from viruses, spyware, hackers and others. Any customer data stored on your computers--including Social Security numbers, bank account information and confidential data, such as key sales and marketing data--is at risk as well. Here are the facts, according to consumer product research organization Consumer Reports: During a recent 24-hour monitoring period, computer security software firm Symantec recorded 59 million attempts by hackers to gain unauthorized entry into business and home computers. One out of four computer users said they had experienced a major, costly problem due to a computer virus, according to a fall 2006 survey. The average cost per incident was $109. In addition, one out of every 115 people was the victim of a scam e-mail attack, which cost victims an average of $850 apiece. To combat viruses and spyware, American consumers spent at least $7.8 billion for computer repairs, parts, and replacement over the past two years. The Threats Since security threats continue to evolve, business owners must not only continue to protect themselves from existing threats such as viruses, spyware and scam e-mails, but must also keep abreast of new threats and understand how hackers will be targeting computers in the future. So what will the newest threats be in 2007? Here are some trends to watch: More narrowly defined threats, or "targeted threats," are becoming common. These attacks tend to focus on sensitive information from a single company or individual rather than indiscriminately letting a worm loose to find victims randomly wherever they can. The "malware" capable of these attacks is being delivered to users in increasingly sophisticated ways such as in e-mail attachments, embedded in video files or hyperlinks, and even through social engineering tactics that lure, fool or trick the user to make what seems like a benign action that automatically installs the malware without user help. Malicious bots--short for robots, or software applications that run automated tasks over the internet --are expected to increase. Bots are sometimes used to create automated attacks on networks, such as DoS attacks. 14 Source: Entrepreneur, as at https://www.entrepreneur.com/article/173760, as at 9th May, 2017. 92 | P a g e Rootkits are increasingly becoming a concern. Rootkits are a set of software tools whose purpose is to conceal processes, files or system data from a computer's operating system. Rootkits can enable hackers to maintain access to a computer system. Because they can burrow deeply, are capable of modifying parts of an operating system, and can go undetected, rootkits can be particularly challenging to remove. Zero-day attacks are also on the rise. A zero-day (also called zero hour) attack takes advantage of computer security holes for which no solution is yet available. They're called "zero day" because they attack between the time a security hole becomes known and the time when a patch to plug the hole is available. As a result, zero-day attacks can spread at an alarming rate. Identity theft will continue to be a growing concern. The FTC estimates that 10 million Americans are victims of identity fraud each year. Hackers who gain unauthorized access to computers are often in search of personal identity data they can exploit or sell. The Solutions Now that you've got some idea what you're up against, is there anything you can really do to protect your business? Absolutely. First, you need to develop a plan that addresses both education and technology. It's critical that you educate your users on what they can do to make sure they're not potentially compromising security (safe user habits for reading and acting upon e-mails can prevent many virus attacks). And make sure unauthorized users (for instance, family or friends) don't use your business's computers. Next, develop a comprehensive technology plan to address all aspects of security. Talk to your trusted IT adviser. Make a complete list of the security you already have in place, with an eye toward sniffing out vulnerabilities. Develop a plan for complete, end-to-end network protection, and make sure there are steps in place to regularly update your security. Then revisit your plan several times a year to ensure it continues to meet your needs and addresses new security threats that continue to evolve. Your plan should include the following security essentials: Antivirus protection. Every PC on your network should have antivirus protection. There are plenty of inexpensive, effective antivirus programs on the market for small and home offices. Antispyware protection. Spyware has become increasingly malicious, difficult to detect and difficult to remove. An antispyware program that frequently downloads updated definitions and monitors activity in the background is important, given the insidious nature of spyware. Firewall. A firewall is designed to block unauthorized access to computers and networks. Firewalls are available in hardware (as standalone network security devices or integrated into network routers) or as software. A software firewall is particularly important for laptop users who travel. Firewall software is usually included in internet security suites, which also offer antivirus, antispyware, and other tools. Some software firewalls are even available in free, basic versions. Virtual private network (VPN). A VPN creates a secure "tunnel" between a computer and an unsecured, public network, such as the internet. VPN technology offers an important layer of protection for your business's weakest security link--mobile users. 93 | P a g e VPN security can be integrated into some network devices, such as intelligent routers, and turned on or off as needed. Wireless security. If your business uses a wireless network, at a minimum, you should use password, WEP key or some other method to block unauthorized users from gaining access. Secure network hardware. Ideally, your company's network should be protected by routers with comprehensive, built-in security, including integrated firewall, VPN and an intrusion prevention system. Data protection. Implementing regular backup procedures is a simple way to safeguard critical business and customer data. Setting permissions and encryption will also help. As I mentioned earlier, maintaining proper security throughout your network is a big job. If it feels overwhelming, consider hiring an IT person to handle the job. Or outsource network security to an independent contractor or managed service provider. The bottom line is, would you like to be in charge of your computers, your network and your data-or would you rather leave that up to a hacker? 94 | P a g e Identify standards against which to engineer the ICT system or application Refer to: AS/NZS ISO/IEC 38500:2010 ISO/IEC 38500:2008 Australian/New Zealand Standard™ Corporate governance of information technology Download from: http://www.professionalsaustralia.org.au/information-technology/wpcontent/uploads/sites/41/2014/11/Standards-Australia-Corporate-Governance-of-IT1.pdf This section provides a range of information about standards directly or peripherally associated with information security within Australia New Zealand, and elsewhere throughout the world. It does not set out to exhaustively list all standards in the known universe that may relate primarily or peripherally to information security15. Those standards listed under Australia/New Zealand are those that have been developed locally. All others are listed as international. Note that a number of international standards (eg ISO standards) apply in Australia and New Zealand. Australia/New Zealand ACSI33 The Defence Signals Directorate has produced the Australian Communications Security Instruction Number 33 (ACSI33) Security Guidelines for Australian Government IT Systems document. This document is available at http://www.dsd.gov.au/library/infosec/acsi33.html . Operating System Checklists AusCERT and the CERT Coordination Center have produced the Windows NT Configuration Guidelines, available from http://www.auscert.org.au/render.html?it=1970 AusCERT has also produced the UNIX Computer Security Checklist, available from http://www.auscert.org.au/render.html?it=1935 International 15 ISO/IEC 17799:2005 Source: AusCERT, as at https://www.auscert.org.au/render.html?it=2248, as on 9th May, 2017. 95 | P a g e The primary information security standard in Australia was AS4444, and in New Zealand was NZS4444. These have been replaced with the international standard, 17799. See Standards Australia OnLine at http://www.standards.com.au. Quality Assurance Services is currently coordinating a certification program for this standard. This certification program is discussed at their Quality Assurance Services web site (http://www.sai-global.com/assuranceservices/certification/InfoSecurityManagement/). ISO/IEC 27001:2005 A widely accepted standard, the British Standard BS 7799 has been updated and published as the international standard ISO/IEC 27001. It was developed by the British Standards Institute ( http://www.bsi-global.com) and is sometimes referred to as BS ISO/IEC 27001:2005. RFC 2196 The Internet Engineering Task Force (IETF) has produced RFC2196 Site Security Handbook, which provides practical guidance to administrators trying to secure their information and services. It is available from http://www.ietf.org/rfc/rfc2196.txt. IT Baseline Protection Manual (Germany) The Federal Agency For Security In Information Technology in Germany has produced the IT Baseline Protection Manual. This document presents a set of recommended standard security measures or "safeguards", as they are referred to in the manual, for typical IT systems. The most recent version is dated October 2000. Further information can be found at http://www.bsi.bund.de/gshb/english/etc/menue.html. OECD Guidelines OECD Guidelines for the Security of Information Systems, are available at http://www.oecd.org/document/42/0,2340,en_2649_34255_15582250_1_1_1_1,00.html. Evaluation Australia/New Zealand Gateway Certification Guide The Defence Signals Directorate has also produced the Gateway Certification Guide, which provides guidelines for independent assessment of an agency gateway. This document is available at http://www.dsd.gov.au/library/infosec/gateway.html. 96 | P a g e DSD EPL The Defence Signals Directorate administers the Australian government's Evaluated Products List. Details are available at http://www.dsd.gov.au/infosec/evaluation_services/epl/epl.html. International ISO 15408 ("Common Criteria") The International Organization for Standardization (ISO) has produced ISO standard IS 15408. This standard, The Common Criteria for Information Technology Security Evaluation v2.1 (ISO IS 15408) is effectively an evolutionary blending of ITSEC (see below), the Canadian criteria, and the US Federal Criteria. It available from http://csrc.nist.gov/cc/ccv20/ccv2list.htm. Rainbow Series ("Orange Book") (US) An important series of documents are the Rainbow Series, which outline a number of security standards developed in the United States. This series is available at http://www.radium.ncsc.mil/tpep/library/rainbow/. Perhaps the most important of these books is the Trusted Computer System Evaluation Criteria (TCSEC, or Orange Book). While this standard has effectively been superseded by other standards outlined above (it is dated 1985), it is nevertheless a useful document. A further document, the US Federal Criteria, was drafted but not adopted in the early 1990's. TCSEC can be found at http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.html Information Technology Security Evaluation Criteria ("ITSEC") (UK) The United Kingdom produced the Information Technology Security Evaluation Criteria (ITSEC) in the early 1990's, and this is another important historical evaluation scheme/standard. It builds on the Orange Book scheme to some extent, with greater granularity. Details about the scheme are available at http://www.itsec.gov.uk/. Development International Capability Maturity Model (CMM) 97 | P a g e The Software Engineering Institute pioneered the development of the Capability Maturity Model, which is method for process maturity assurance. Details are available at http://www.sei.cmu.edu/cmm/cmms/cmms.html. System Security Engineering Capability Maturity Model (SSE-CMM) A derivative of this work is the System Security Engineering Capability Maturity Model. Details are available at http://www.sse-cmm.org/. Financial Australia/New Zealand AS2805 ("Electronic funds transfer") Standards Australia has a standard for electronic payment implementation. The standard is AS2805, specifically AS 2805.4-1985 Electronic funds transfer - Requirements for interfaces Message authentication and AS 2805.4.1-2001 Electronic funds transfer - Requirements for interfaces - Message authentication - Mechanisms using a block cipher. These standards are available by accessing the Standards Australia OnLine Catalogue and searching on Australian standard number 2805. International ISO 11131 ("Banking and Related Financial Services; Sign-on Authentication") ISO 11131:1992 Banking and Related Financial Services; Sign-on Authentication is available by accessing the Standards Australia OnLine Catalogue and searching on ISO standard number 11131. ISO 13569 ("Banking and Related Financial Services -- Information Security Guidelines") ISO 13569:1997 Banking and Related Financial Services -- Information Security Guidelines (several documents) is available by accessing the Standards Australia OnLine Catalogue and searching on ISO standard number 13569. Risk Australia/New Zealand AS/NZS 4360 ("Risk Management") Australian/New Zealand Standard AS/NZS 4360:1999 Risk Management. More information is available by accessing the Standards Australia OnLine Catalogue and searching on Australian standard number 4360. 98 | P a g e Associated documents that may be of interest are HB 231:2000 Information security risk management guidelines and HB 240:2000 Guidelines for managing risk in outsourcing utilizing the AS/NZS 4360 process. More information is available by accessing the Standards Australia OnLine Catalogue and searching on HB 231 and HB 240 respectively. International Acquisition Risk Management (US) The Software Engineering Institute has some discussion on Acquisition Risk Management. Details are available at http://www.sei.cmu.edu/arm/index.html. Authentication Australia/New Zealand AS4539 ("Information technology - Public Key Authentication Framework") Public Key authentication systems are governed by several documents that fall under Australian Standard 4539 Information technology - Public Key Authentication Framework. More information is available by accessing the Standards Australia OnLine Catalogue and searching on Australian standard number 4539. International ISO 11131 ("Banking and Related Financial Services; Sign-on Authentication") ISO 11131:1992 Banking and Related Financial Services; Sign-on Authentication is available by accessing the Standards Australia OnLine Catalogue and searching on ISO standard number 11131. Activity 4 Select one standard applicable to ICT systems or applications and describe how you would apply the standard to an organisation’s ICT system or application. 99 | P a g e Activity 4 100 | P a g e Activity 4 101 | P a g e Identify criteria for performing risk based audits against the ICT system or application Taking a risk-based approach to IT audit can help focus limited resources on the real threats16 Fast-moving changes in technology have added to the potential risks companies face. It is not always easy for senior management to wrap its arms around information technology risks confronting their organization. However, internal audit departments can help shed light on the issue through risk-based IT audit planning. One way of looking at the subject is simply put: There are no IT risks as such. Rather, it is all about business risks and how IT might impact the business. The first step before embarking on a risk-based IT audit involves sorting out the IT audit universe. That means pinpointing all the relevant auditable IT entities including: operating systems, databases and networks, as well as the types of computers in the system and their physical location. Is the underlying operating system UNIX, Windows? Is the platform a mainframe or client server? Companies taking this approach will want to measure all of these entities and then focus their limited audit resources on risks that could have the greatest impact on the business. How you determine what to audit and in what sequence will be based on the risk criteria used to identify the significance of, and likelihood that, conditions or events may occur that would hurt the organization. Examples include the ethical climate and pressure on management to meet objectives; competency, adequacy and integrity of personnel; financial and economic conditions; asset size, liquidity or transaction volume; competitive conditions; and complexity or volatility of activities. Heading the list of IT risk factors is information criticality. Think of it in terms of an acronym CIA: Confidentiality, Integrity and Availability. These three factors are generally considered the pillars of information security. Confidentiality is essential to protect personally identifiable information and guard company secrets from inadvertent disclosure. A classic example of an IT security breach happened five years ago when the home of an employee of the U.S. Department of Veterans Affairs was burglarized and data stored on a laptop computer– sensitive records on 26.5 million veterans— was stolen. In the aftermath, the government made laptop hard drive encryption mandatory and many corporations adopted the same policy. Integrity needs to be in place in application systems so employees can trust that the output can be relied upon for completeness and accuracy. Availability refers to the assurance that the information is accessible to the people who require it when they need it and that there are adequate backup and disaster recovery systems in place. 16 Source: MIS Training Institute, as at http://misti.com/internal-audit-insights/understanding-risk-based-itaudit-planning, as on 9th May, 2017. 102 | P a g e Besides the CIA criteria, some other IT risk factors to consider include the following: 1. Materiality: Will it affect the entire company or only a part? 2. Reputational fallout: The now-defunct Arthur Andersen is frequently cited as an example of how a damaged name can cause clients to flee. 3. Strategic plan support: Is it a new project or system? If it is, how big is it and what business risk does it entail? 4. Fraud: What system-based controls are in place to help monitor and prevent fraudulent activity? 5. Outsourced risk: Can we rely on the controls of a third-party vendor? 6. Changes in the audit environment: Did something occur that needs a closer look? When was the last time an audit was conducted and what was the audit opinion/conclusion? The CIA concept avoids often-confusing technical jargon and is something everyone – from C-level leaders to board of directors to business management can relate to. The Institute of Internal Auditors’ Global Technology Audit Guide on IT Controls suggests a number of basic questions for an IT risk assessment: 1. What could happen to affect an information asset value adversely (threat event)? 2. If a threat event happened, how bad could its impact be? 3. How often might the event be expected to occur? 4. What can be done to reduce the risk? 5. How much will it cost to reduce the risk? 6. Is it cost-efficient? Identifying critical information assets and systems, based on business objectives and information assets, is the starting point in the IT risk assessment process. What business systems house information and support critical business functions? Is it payroll, general ledger system, or the accounts payable system? You also will want to determine system support infrastructures (that is, IT general controls), including hardware, operating systems, database management systems, networks and information processing facilities. Keep in mind, application risk drives infrastructure risk. For example, if a company identifies payroll as a high-risk application, the IT infrastructure components that support that application get the same risk. How does the risk-based IT audit planning process relate to the integrated auditing concept? By definition, integrated auditing is an integrated or coordinated effort between business audit and technical audit to provide application audit coverage of key business risks. That is, integrated auditing is about auditing the business process and underlying key IT components. Those conducting an integrated audit need to audit the key supporting IT components – operating system, data base, etc. – either before, as part of, or shortly after the integrated audit. At some point you must look at those high-risk IT components as they relate back to the business. As noted earlier, it’s all about business risks and how IT might impact the business. 103 | P a g e Things get trickier when a company outsources IT functions. The risk increases in such a situation and makes it substantially difficult to assess those controls. The question becomes: Does this thirdparty vendor have good controls? And how do you assess those controls? Because management is accountable for the successful operation of the business, it’s important that they understand the potential risks the organization faces through its IT system. In the past, the conventional wisdom was that “as long as IT is doing a good job, I’m OK.” Now it’s a different ball game: you could be in major trouble if your systems aren’t secure. Regulations such as SOX, PCI and HIPPA have forced management to understand the potential risks to the IT system. Remember, controls are only as good as top leadership wants to make them. Management, once complacent about earmarking resources for IT, can no longer afford to ignore this critical investment. An information system (IS) audit or information technology(IT) audit is an examination of the controls within an entity's Information technology infrastructure. These reviews may be performed in conjunction with a financial statement audit, internal audit, or other form of attestation engagement. It is the process of collecting and evaluating evidence of an organization's information systems, practices, and operations. Obtained evidence evaluation can ensure whether the organization's information systems safeguard assets, maintains data integrity, and are operating effectively and efficiently to achieve the organization's goals or objectives17. An IS audit is not entirely similar to a financial statement audit. An evaluation of internal controls may or may not take place in an IS audit. Reliance on internal controls is a unique characteristic of a financial audit. An evaluation of internal controls is necessary in a financial audit, in order to allow the auditor to place reliance on the internal controls, and therefore, substantially reduce the amount of testing necessary to form an opinion regarding the financial statements of the company. An IS audit, on the other hand, tends to focus on determining risks that are relevant to information assets, and in assessing controls in order to reduce or mitigate these risks. An IT audit may take the form of a "general control review" or an "specific control review". Regarding the protection of information assets, one purpose of an IS audit is to review and evaluate an organization's information system's availability, confidentiality, and integrity by answering the following questions: 1. Will the organization's computerized systems be available for the business at all times when required? (Availability) 2. Will the information in the systems be disclosed only to authorized users? (Confidentiality) 3. Will the information provided by the system always be accurate, reliable, and timely? (Integrity). The performance of an IS Audit covers several facets of the financial and organizational functions of our Clients. The diagram to the right gives you an overview of the Information Systems Audit flow: From Financial Statements to the Control Environment and Information Systems Platforms. 17 Source: Wiki Educator, as at http://wikieducator.org/Information_Systems_Audit_Methodology, as on 9th May, 2017. 104 | P a g e Information Systems Audit Methodology Our methodology has been developed in accordance with International Information Systems Audit Standards e.g ISACA Information Systems Audit Standards and Guidelines and the Sabarne Oxley COSO Standard. The beginning point of this methodology is to carry out planning activities that are geared towards integrating a Risk Based Audit Approach to the IS Audit. PHASE 1: Audit Planning In this phase we plan the information system coverage to comply with the audit objectives specified by the Client and ensure compliance to all Laws and Professional Standards. The first thing is to obtain an Audit Charter from the Client detailing the purpose of the audit, the management responsibility, authority and accountability of the Information Systems Audit function as follows: 1. Responsibility: The Audit Charter should define the mission, aims, goals and objectives of the Information System Audit. At this stage we also define the Key Performance Indicators and an Audit Evaluation process; 2. Authority: The Audit Charter should clearly specify the Authority assigned to the Information Systems Auditors with relation to the Risk Assessment work that will be carried out, right to access the Client’s information, the scope and/or limitations to the scope, the Client’s functions to be audited and the auditee expectations; and 3. Accountability: The Audit Charter should clearly define reporting lines, appraisals, assessment of compliance and agreed actions. The Audit Charter should be approved and agreed upon by an appropriate level within the Client’s Organization. 105 | P a g e See Template for an Audit Charter/ Engagement Letter here. In addition to the Audit Charter, we should be able to obtain a written representation (“Letter of Representation”) from the Client’s Management acknowledging: 1. Their responsibility for the design and implementation of the Internal Control Systems affecting the IT Systems and processes 2. Their willingness to disclose to the Information Systems Auditor their knowledge of irregularities and/or illegal acts affecting their organisation pertaining to management and employees with significant roles within the internal audit department. 3. Their willingness to disclose to the IS Auditor the results of any risk assessment that a material misstatement may have occurred See a Template for a Letter of Representation here. PHASE 2 – Risk Assessment and Business Process Analysis Risk is the possibility of an act or event occurring that would have an adverse effect on the organisation and its information systems. Risk can also be the potential that a given threat will exploit vulnerabilities of an asset or group of assets to cause loss of, or damage to, the assets. It is ordinarily measured by a combination of effect and likelihood of occurrence. More and more organisations are moving to a risk-based audit approach that can be adapted to develop and improve the continuous audit process. This approach is used to assess risk and to assist an IS auditor’s decision to do either compliance testing or substantive testing. In a risk based audit approach, IS auditors are not just relying on risk. They are also relying on internal and operational controls as well as knowledge of the organisation. This type of risk assessment decision can help relate the cost/benefit analysis of the control to the known risk, allowing practical choices. The process of quantifying risk is called Risk Assessment. Risk Assessment is useful in making decisions such as: 1. The area/business function to be audited 2. The nature, extent and timing of audit procedures 3. The amount of resources to be allocated to an audit The following types of risks should be considered: Inherent Risk: Inherent risk is the susceptibility of an audit area to error which could be material, individually or in combination with other errors, assuming that there were no related internal controls. In assessing the inherent risk, the IS auditor should consider both pervasive and detailed IS controls. This does not apply to circumstances where the IS auditor’s assignment is related to pervasive IS controls only. A pervasive IS Control are general controls which are designed to manage and monitor the IS environment and which therefore affect all IS-related activities. Some of the pervasive IS Controls that an auditor may consider include: The integrity of IS management and IS management experience and knowledge 106 | P a g e Changes in IS management Pressures on IS management which may predispose them to conceal or misstate information (e.g. large business-critical project over-runs, and hacker activity) The nature of the organisation’s business and systems (e.g., the plans for electronic commerce, the complexity of the systems, and the lack of integrated systems) Factors affecting the organisation’s industry as a whole (e.g., changes in technology, and IS staff availability) The level of third party influence on the control of the systems being audited (e.g., because of supply chain integration, outsourced IS processes, joint business ventures, and direct access by customers) Findings from and date of previous audits A detailed IS control is a control over acquisition, implementation, delivery and support of IS systems and services. The IS auditor should consider, to the level appropriate for the audit area in question: The findings from and date of previous audits in this area The complexity of the systems involved The level of manual intervention required The susceptibility to loss or misappropriation of the assets controlled by the system (e.g., inventory, and payroll) The likelihood of activity peaks at certain times in the audit period Activities outside the day-to-day routine of IS processing (e.g., the use of operating system utilities to amend data) The integrity, experience and skills of the management and staff involved in applying the IS controls Control Risk: Control risk is the risk that an error which could occur in an audit area, and which could be material, individually or in combination with other errors, will not be prevented or detected and corrected on a timely basis by the internal control system. For example, the control risk associated with manual reviews of computer logs can be high because activities requiring investigation are often easily missed owing to the volume of logged information. The control risk associated with computerised data validation procedures is ordinarily low because the processes are consistently applied. The IS auditor should assess the control risk as high unless relevant internal controls are: Identified Evaluated as effective Tested and proved to be operating appropriately Detection Risk: Detection risk is the risk that the IS auditor’s substantive procedures will not detect an error which could be material, individually or in combination with other errors. In determining the level of substantive testing required, the IS auditor should consider both: The assessment of inherent risk The conclusion reached on control risk following compliance testing The higher the assessment of inherent and control risk the more audit evidence the IS auditor should normally obtain from the performance of substantive audit procedures. 107 | P a g e Our Risk Based Information Systems Audit Approach A risk based approach to an Information Systems Audit will enable us to develop an overall and effective IS Audit plan which will consider all the potential weaknesses and /or absence of Controls and determine whether this could lead to a significant deficiency or material weakness. In order to perform an effective Risk Assessment, we will need to understand the Client’s Business Environment and Operations. Usually the first phase in carrying out a Risk Based IS Audit is to obtain an understanding of the Audit Universe. In understanding the Audit Universe we perform the following: Identify areas where the risk is unacceptably high Identify critical control systems that address high inherent risks 108 | P a g e Assess the uncertainty that exists in relation to the critical control systems In carrying out the Business Process Analysis we: Obtain an understanding of the Client Business Processes Map the Internal Control Environment Identify areas of Control Weaknesses The Chat to the right summarises the business process analysis phase. The template xxx will provide you with a guideline to document an Organisations Business Sub Processes identified during the risk analysis phase.For each of the sub-processes, we identify a list of What Could Go Wrong (WCGW). This WCGW represent the threat existing on a particular process. A single process would have multiple WCGW’s. For each of the WCGW’s identified in the prior phase we will determine the Key Activities within that process.For each Key Activity: 1. We will identify the Information Systems Controls 2. For each of the Controls Identified, we would rate the impact/effect of the lack of that control (on a rating of 1 - 5, with 5 indicating the highest impact),we will then determine the likelyhood of the threat occuring( also on a rating of 1 - 5 with 5 representing the highest likelyhood). PHASE 3 – Performance of Audit Work 109 | P a g e In the performance of Audit Work the Information Systems Audit Standards require us t o provide supervision, gather audit evidence and document our audit work. We achieve this objective through: Establishing an Internal Review Process where the work of one person is reviewed by another, preferably a more senior person. We obtain sufficient, reliable and relevant evidence to be obtained through Inspection, Observation, Inquiry, Confirmation and recomputation of calculations We document our work by describing audit work done and audit evidence gathered to support the auditors’ findings. Based on our risk assessment and upon the identification of the risky areas, we move ahead to develop an Audit Plan and Audit Program. The Audit Plan will detail the nature, objectives, timing and the extent of the resources required in the audit. See Template for a Sample Audit Plan. Based on the compliance testing carried out in the prior phase, we develop an audit program detailing the nature, timing and extent of the audit procedures. In the Audit Plan various Control Tests and Reviews can be done. They are sub-divided into: 1. General/ Pervasive Controls 2. Specific Controls 110 | P a g e The Chat below to the left shows the Control Review Tests that can be performed in the two Control Tests above. Control Objectives for Information and related Technology (COBIT) The Control Objectives for Information and related Technology (COBIT) is a set of best practices (framework) for information (IT) management created by the Information Systems Audit and Control Association (ISACA), and the IT Governance Institute (ITGI) in 1992. COBIT provides managers, auditors, and IT users with a set of generally accepted measures, indicators, processes and best practices to assist them in maximizing the benefits derived through the use of information technology and developing appropriate IT governance and control in a company. 111 | P a g e COBIT helps meet the multiple needs of management by bridging the gaps between business risks, control needs and technical issues. It provides a best practices framework for managing IT resources and presents management control activities in a manageable and logical structure. This framework will help optimise technology information investments and will provide a suitable benchmark measure. The Framework comprises a set of 34 high-level Control Objectives, one for each of the IT processes listed in the framework. These are then grouped into four domains: planning and organisation, acquisition and implementation, delivery and support, and monitoring. This structure covers all aspects of information processing and storage and the technology that supports it. By addressing these 34 high-level control objectives, we will ensure that an adequate control system is provided for the IT environment. A diagrammatic representation of the framework is shown below. 112 | P a g e We shall apply the COBIT framework in planning, executing and reporting the results of the audit. This will enable us to review the General Controls Associated with IT Governance Issues. Our review shall cover the following domains; Planning and organisation of information resources; The planning and acquisition of systems and path in stage growth model of information systems; The delivery and support of the IS/IT including facilities, operations, utilisation and access; Monitoring of the processes surrounding the information systems; The level of effectiveness, efficiency, confidentiality, integrity, availability, compliance and reliability associated with the information held in; and The level of utilisation of IT resources available within the environment of the IS including people, the application systems of interface, technology, facilities and data. The above control objectives will be matched with the business control objectives to apply specific audit procedures that will provide information on the controls built in the application, indicating areas of improvement that we need to focus on achieving. Application Control Review An Application Control Review will provide management with reasonable assurance that transactions are processed as intended and the information from the system is accurate, complete and timely. An Application Controls review will check whether: Controls effectiveness and efficiency Applications Security Whether the application performs as expected A Review of the Application Controls will cover an evaluation of a transaction life cycle from Data origination, preparation, input, transmission, processing and output as follows: 1. Data Origination controls are controls established to prepare and authorize data to be entered into an application. The evaluation will involve a review of source document design and storage, User procedures and manuals, Special purpose forms, Transaction ID codes, Cross reference indices and Alternate documents where applicable. It will also involve a review of the authorization procedures and separation of duties in the data capture process. 2. Input preparation controls are controls relating to Transaction numbering, Batch serial numbering, Processing, Logs analysis and a review of transmittal and turnaround documents 3. Transmission controls involve batch proofing and balancing, Processing schedules, Review of Error messages, corrections monitoring and transaction security 4. Processing controls ensure the integrity of the data as it undergoes the processing phase including Relational Database Controls, Data Storage and Retrieval 5. Output controls procedures involve procedures relating to report distribution, reconciliation, output error processing, records retention. 113 | P a g e The use of Computer Aided Audit Techniques (CAATS) in the performance of an IS Audit The Information Systems Audit Standards require us that during the course of an audit, the IS auditor should obtain sufficient, reliable and relevant evidence to achieve the audit objectives. The audit findings and conclusions are to be supported by the appropriate analysis and interpretation of this evidence. CAATs are useful in achieving this objective. Computer Assisted Audit Techniques (CAATs) are important tools for the IS auditor in performing audits. They include many types of tools and techniques, such as generalized audit software, utility software, test data, application software tracing and mapping, and audit expert systems. For us, our CAATs include ACL Data Analysis Software and the Information Systems Audit Toolkit(ISAT). CAATs may be used in performing various audit procedures including: Tests of details of transactions and balances(Substantive Tests) Analytical review procedures Compliance tests of IS general controls Compliance tests of IS application controls CAATs may produce a large proportion of the audit evidence developed on IS audits and, as a result, the IS auditor should carefully plan for and exhibit due professional care in the use of CAATs. The major steps to be undertaken by the IS auditor in preparing for the application of the selected CAATs are: Set the audit objectives of the CAATs Determine the accessibility and availability of the organisation’s IS facilities, programs/system and data Define the procedures to be undertaken (e.g., statistical sampling, recalculation, confirmation, etc.) Define output requirements Determine resource requirements, i.e., personnel, CAATs, processing environment (organisation’s IS facilities or audit IS facilities) Obtain access to the client’s IS facilities, programs/system, and data, including file definitions Document CAATs to be used, including objectives, high-level flowcharts, and run instructions Make appropriate arrangements with the Auditee and ensure that: 1. Data files, such as detailed transaction files are retained and made available before the onset of the audit. 2. You have obtained sufficient rights to the client’s IS facilities, programs/system, and data 3. Tests have been properly scheduled to minimise the effect on the organisation’s production environment. 4. The effect that changes to the production programs/system have been properly considered. See Template here for example tests that you can perform with ACL PHASE 4: Reporting 114 | P a g e Upon the performance of the audit test, the Information Systems Auditor is required to produce and appropriate report communicating the results of the IS Audit. An IS Audit report should: 1. Identify an organization, intended recipients and any restrictions on circulation 2. State the scope, objectives, period of coverage, nature, timing and the extend of the audit work 3. State findings, conclusions, recommendations and any reservations, qualifications and limitations 4. Provide audit evidence Activity 5 What is a risk based audit? 115 | P a g e Activity 5 116 | P a g e Activity 5 The Internet continues to grow exponentially. Personal, government, and business applications continue to multiply on the Internet, with immediate benefits to end users. However, these network-based applications and services can pose security risks to individuals and to the information resources of companies and governments. Information is an asset that must be protected. Without adequate network security, many individuals, businesses, and governments risk losing that asset18. 18 Source: Love My Tool, as at http://www.lovemytool.com/files/vulnerabilities-threats-and-attacks-chapterone-7.pdf, as on 9th May, 2017. 117 | P a g e Network security is the process by which digital information assets are protected. The goals of network security are as follows: Protect confidentiality Maintain integrity Ensure availability With this in mind, it is imperative that all networks be protected from threats and vulnerabilities for a business to achieve its fullest potential. Typically, these threats are persistent because of vulnerabilities, which can arise from the following: Not all required commands are covered in sufficient detail in the text alone. Successful completion of this course requires a thorough knowledge of command syntax and application. Misconfigured hardware or software Poor network design Inherent technology weaknesses End-user carelessness Intentional end-user acts (that is, disgruntled employees) Introduction to Network Security This chapter consists of an overview of what network security is all about. The sections that follow cover the following aspects of network security: The need for network security Identifying potential risks to network security Open versus closed security models Trends driving network security Information security organizations The Need for Network Security Security has one purpose: to protect assets. For most of history, this meant building strong walls to stop the enemy and establishing small, well-guarded doors to provide secure access for friends. This strategy worked well for the centralized, fortress-like world of mainframe computers and closed networks, as seen in Figure 1-1. 118 | P a g e The closed network typically consists of a network designed and implemented in a corporate environment and provides connectivity only to known parties and sites without connecting to public networks. Networks were designed this way in the past and thought to be reasonably secure because of no outside connectivity. With the advent of personal computers, LANs, and the wide-open world of the Internet, the networks of today are more open, as shown in Figure 1-2. As e-business and Internet applications continue to grow, the key to network security lies in defining the balance between a closed and open network and differentiating the good guys from the bad guys. With the increased number of LANs and personal computers, the Internet began to create untold numbers of security risks. Firewall devices, which are software or hardware that enforce an access control policy between two or more networks, were introduced. This technology gave businesses a balance between security and simple outbound access to the Internet, which was mostly used for email and web surfing. 119 | P a g e This balance was short-lived as the use of extranets began to grow, which connected internal and external business processes. Businesses were soon realizing tremendous cost savings by connecting supply-chain management and enterprise resource planning systems to their business partners, and by connecting sales-force automation systems to mobile employees, and by providing electronic commerce connections to business customers and consumers. The firewall began to include intrusion detection, authentication, authorization, and vulnerability-assessment systems. Today, successful companies have again struck a balance by keeping the enemies out with increasingly complex ways of letting friends in. Most people expect security measures to ensure the following: Users can perform only authorized tasks. Users can obtain only authorized information. Users cannot cause damage to the data, applications, or operating environment of a system. The word security means protection against malicious attack by outsiders (and by insiders). Statistically, there are more attacks from inside sources. Security also involves controlling the effects of errors and equipment failures. Anything that can protect against an attack will probably prevent random misfortunes, too. Throughout this book, many definitions, acronyms, and logical device symbols dealing with security are introduced (see Figure 1-3). Refer to the glossary for further explanation when encountering unknown terms and acronyms. 120 | P a g e Identifying Potential Risks to Network Security A risk analysis should identify the risks to the network, network resources, and data. The intent of a risk analysis is to identify the components of the network, evaluate the importance of each component, and then apply an appropriate level of security. This analysis helps to maintain a workable balance between security and required network access. The key is to identify what needs to be secured and at what cost. More money and assets would be allocated ensuring the security of a high-priced automobile versus an old junker, for example. Asset Identification Before the network can be secured, you must identify the individual components that make up the network. You need to create an asset inventory that includes all the network devices and endpoints, such as hosts and servers. Vulnerability Assessment After you have identified the network components, you can assess their vulnerabilities. These vulnerabilities could be weaknesses in the technology, configuration, or security policy. Any vulnerability you discover must be addressed to mitigate any threat that could take advantage of the vulnerability. Vulnerabilities can be fixed by various methods, including applying software patches, reconfiguring devices, or deploying countermeasures, such as firewalls and antivirus software. Many websites list the vulnerabilities of network components, and the manufacturers of operating systems and components that list vulnerabilities of their products sponsor many websites. Threat Identification A threat is an event that can take advantage of vulnerability and cause a negative impact on the network. Potential threats to the network need to be identified, and the related vulnerabilities need to be addressed to minimize the risk of the threat. Open Versus Closed Security Models 121 | P a g e With all security designs, some trade-off occurs between user productivity and security measures. The goal of any security design is to provide maximum security with minimum impact on user access and productivity. Some security measures, such as network data encryption, do not restrict access and productivity. On the other hand, cumbersome or unnecessarily redundant verification and authorization systems can frustrate users and prevent access to critical network resources. Remember that the network is a tool designed to enhance production. If the security measures that are put in place become too cumbersome, they will actually detract rather than enhance productivity. Networks used as productivity tools should be designed so that business needs dictate the security policy. A security policy should not determine how a business operates. Because organizations are constantly subject to change, security policies must be systematically updated to reflect new business directions, technological changes, and resource allocations. Security policies vary greatly in design. Three general types of security models are open, restrictive, and closed. Some important points are as follows (see Figure 1-4): Security model can be open or closed as a starting point. Choose the best end-to-end mix of security products and technology to implement the model. Application-level security can include Secure Sockets Layer (SSL) technology. Like security models, many devices can be classified as open, restrictive, or closed. For example, routers and switches are typically open devices, allowing high functionality and services by default. On the other hand, a firewall is typically a closed system that does not allow any services until they are switched on. Server operating systems can fall into any of the three categories, depending on the vendor. It is important to understand these principles when deploying these devices. 122 | P a g e Open Access An open security model is the easiest to implement, as shown in Figures 1-5 and 1-6. Few security measures are implemented in this design. Administrators configure existing hardware and software basic security capabilities. Firewalls, virtual private networks (VPNs), intrusion detection systems (IDSs), and other measures that incur additional costs are typically not implemented. Simple passwords and server security become the foundation of this model. If encryption is used, it is implemented by individual users or on servers. 123 | P a g e This model assumes that the protected assets are minimal, users are trusted, and threats are minimal. However, this does not exclude the need for data backup systems in most open security policy scenarios. LANs that are not connected to the Internet or public WANs are more likely to implement this type of model. This type of network design gives users free access to all areas. When security breaches occur, they are likely to result in great damage and loss. Network administrators are usually not held responsible for network breaches or abuse. Restrictive Access A restrictive security model is more difficult to implement, as shown in Figures 1-7 and 1-8. Many security measures are implemented in this design. Administrators configure existing hardware and software for security capabilities in addition to deploying more costly hardware and software solutions such as firewalls, VPNs, IDSs, and identity servers. Firewalls and identity servers become the foundation of this model. 124 | P a g e This model assumes that the protected assets are substantial, some users are not trustworthy, and that threats are likely. LANs that are connected to the Internet or public WANs are more likely to implement this type of model. Ease of use for users diminishes as security tightens. 125 | P a g e Closed Access A closed security model is most difficult to implement. All available security measures are implemented in this design. Administrators configure existing hardware and software for maximumsecurity capabilities in addition to deploying more costly hardware and software solutions such as firewalls, VPNs, IDSs, and identity servers, as shown in Figures 1-9 and 1-10. 126 | P a g e The closed security model assumes that the protected assets are premium, all users are not trustworthy, and that threats are frequent. User access is difficult and cumbersome. Network administrators require greater skills and more time to administer the network. Furthermore, companies require a higher number of and better trained network administrators to maintain this tight security. In many corporations and organizations, these administrators are likely to be unpopular while implementing and maintaining security. Network security departments must clarify that they only implement the policy, which is designed, written, and approved by the corporation. Politics behind the closed security model can be monumental. In the event of a security breach or network outage, network administrators might be held more accountable for problems. Trends Driving Network Security As in any fast-growing industry, changes are to be expected. The types of potential threats to network security are always evolving. If the security of the network is compromised, there could be serious consequences, such as loss of privacy, theft of information, and even legal liability. Figure 111 illustrates several threats and their potential consequences. 127 | P a g e 128 | P a g e Develop processes and procedures to mitigate the introduction of vulnerabilities during the engineering process Information Technology Threats and Vulnerabilities19 A threat and a vulnerability are not one and the same. A threat is a person or event that has the potential for impacting a valuable resource in a negative manner. A vulnerability is that quality of a resource or its environment that allows the threat to be realized. An armed bank robber is an example of a threat. A bank teller is an example of a valuable resource that may be vulnerable during a bank robbery. Bullet-proof glass between the robber and the teller denies the robber the opportunity to shoot the teller. The threat remains present, but one of its harmful effects (a gunshot) has been mitigated by a protection mechanism (the glass). In system and network security, the threats remain present but are mitigated through the proper use of security features and procedures. Mitigation is any effort to prevent the threat from having a negative impact, or to limit the damage where total prevention is not possible, or to improve the speed or effectiveness of the recovery effort. Hardware and software systems and the data they process can be vulnerable to a wide variety of threats. 19 Source: NASA, as at https://www.hq.nasa.gov/security/it_threats_vulnerabilities.htm, as on 9th May, 2017. 129 | P a g e The selection of security features and procedures must be based not only on general security objectives but also on the specific vulnerabilities of the system in question in light of the threats to which the system is exposed. It is possible to over-protect, which only wastes resources and inconveniences users. As you can see, there is a relationship between threats and vulnerabilities. Sometimes it is easier to examine each potential threat and determine the extent to which you are vulnerable (e.g. fire, flood, earthquake). In other cases it is easier to look for potential vulnerabilities with no particular threat in mind (e.g. improper mounting of equipment, media failure, data entry error). In order to arrive at a complete risk assessment, both perspectives must be examined. Threats and vulnerabilities are intermixed in the following list and can be referred to collectively as potential "security concerns." For ease of discussion and use, concerns can be divided into four categories. Environmental concerns include undesirable site-specific chance occurrences such as lightning, dust and sprinkler activation. Physical concerns include undesirable site-specific personnel actions, either intentional or unintentional, such as theft, vandalism and trip hazards. Site-Support concerns include foundational site aspects such as electrical power, telephone service and climate control. These three categories of concerns are generally not resolvable as part of system design and administration - they are more appropriately addressed as part of facility design and maintenance, thereby encompassing all systems present. The final category, Technical concerns, includes insidious system-specific situations such as improper system operation, malicious software and line tapping. The actual threats are few: untrained and nefarious users and system calamities. It is far more useful to explore the many avenues (vulnerabilities) open to these users and events, and to consider ways to prevent these occurrences and/or provide for rapid recovery. The following list is meant to be used as a starting point in any IT risk assessment. Each potential concern must be evaluated for a particular site or system to determine the extent to which it applies. The probability of its occurrence, coupled with the projected impact of the event and the cost of the appropriate mitigation yields a prioritized list of security concerns that should be addressed. Environmental (undesirable site-specific chance occurrences) Fire Flood Tsunami Earthquake Volcanic Eruptions Lightning Severe Weather Smoke Dust Insects Rodents Chemical Fumes 130 | P a g e Sprinkler Activation Water Leakage - pipe breakage, hole in roof, condensation Explosion - nearby gas line, chemical plant, tank farm, munitions depot Vibration - nearby railroad track, jet traffic, construction site Electromagnetic Interference - suggested by poor radio reception or jittery workstation displays Electrostatic Discharge - suggested by "sparking" to grounded objects Physical (undesirable site-specific personnel actions) Unauthorized Facility Access Theft Vandalism Sabotage Extortion Terrorism / Bomb Threat Labor Unrest - employees and support contractors War / Civil Unrest Improper Transportation - equipment dropped, submerged, exposed to weather or X-rayed in transit Improper Mounting/Storage - equipment exposed to bumps, kicks or weather Spillage / Droppage - hazardous materials permitted near equipment (e.g. food, liquids) Magnets / Magnetic Tools - can erase data or damage sensitive equipment Collision - fork lift, auto, plane, wheelchair Trip Hazards / Falls - equipment poses personnel hazards Fire Hazards - flammable materials stored nearby Site-Support (foundational site aspects) Power Outage Extreme / Unstable Temperatures Extreme / Unstable Humidity Unsafe Environment - unfit for human occupation Facility Inaccessibility - blocked ingress Inability to Cut Power - during fire, flood, etc. Electrical Noise / Bad Ground - suggested by flickering lights or jittery workstation displays Improper Maintenance - unqualified support or preventive maintenance behind schedule Personnel Unavailability - inability to contact operations or support personnel Telephone Failure - inability to contact site from outside, inability to call out, service completely unavailable Inappropriate Fire Suppression - water, foam, PKP, Halon Inappropriate Trash Disposal - sensitive data released in an unauthorized manner Technical (insidious system-specific situations) Improper / Inadequate Procedure - foreseeable events not supported by complete and accurate documentation and training 131 | P a g e Improper Operation - operating equipment beyond capacity or outside of manufacturer's constraints Improper Hardware Configuration - prescribed hardware configured in other than the prescribed manner during installation Improper Software Configuration - prescribed software configured in other than the prescribed manner during installation Unauthorized Hardware / Modification - adding other-than-prescribed hardware or making unauthorized hardware modifications Unauthorized Software / Modification - adding other-than-prescribed software or making unauthorized software modifications Unauthorized Software Duplication - creating copies of licensed software that are not covered by a valid license Unauthorized Logical Access - acquiring the use of a system for which no access has been authorized (as opposed to gaining physical access to the hardware) Malfeasance (exceeding authorizations) - acquiring the use of a system in excess of that which has been authorized Unsanctioned Use / Exceeding Licensing - utilizing authorized system resources for unauthorized purposes (resume, church bulletin, non-job-related e-mail or Internet browsing) or exceeding a user licensing agreement Over- or Under-Classification - labelling of a resource at a higher or lower level of sensitivity than appropriate Malicious Software - software whose purpose is to degrade system performance, modify or destroy data, steal resources or subvert security in any manner Hardware Error / Failure [functionality] - hardware that stops providing the desired user services/resources Hardware Error / Failure [security] - hardware that stops providing the desired security services/resources Software Error / Failure [functionality] - software that stops providing the desired user services/resources Software Error / Failure [security] - software that stops providing the desired security services/resources Media Failure - storage media that stops retaining stored information in a retrievable/intact manner Data Remanence - storage media that retains stored information in a retrievable/intact manner longer than desired (failure to totally erase) Object Reuse - a system providing the user with a storage object (e.g. memory or disk space) that contains useful information belonging to another user Communications Failure / Overload - a communications facility that stops providing service or is unable to provide service at the requested capacity Communications Error - a communications facility that provides inaccurate service Data Entry Error - a system accepting erroneous data as legitimate Accidental Software Modification / Deletion - deleting or otherwise making unavailable necessary software Accidental Data Modification / Deletion - deleting or otherwise making unavailable necessary data Accidental Data Disclosure - inadvertently revealing sensitive data to an unauthorized user Repudiation - participating in a process or transaction but then denying having done so 132 | P a g e Masquerading - participating in a process or transaction but posing as another user Message Playback - recording a legitimate transmission for retransmission at a later time in an attempt to gain unauthorized privileges Message Flooding - generating an inordinately large quantity of transmissions in an attempt to make a system or service unavailable due to overload Line Tapping - connecting to a communications facility in an unauthorized manner in an attempt to glean useful information Electronic Emanations - information-bearing spurious emissions associated with all electronic equipment (prevented by TEMPEST equipment or shielding) Geo-location - a system inadvertently revealing the current physical location of a user NOTE: The above list of Technical concerns is somewhat generic but is useful during system design and remains useful at a high level during system audits; a more detailed list of system-specific vulnerabilities would be so long and dynamic as to be unmanageable automated tools should be used to identify operating system-, application- and middleware-specific vulnerabilities. Eliminating Vulnerabilities Upfront20 The final security architecture and non-technical controls should attempt to eliminate as many of the security vulnerabilities as possible, and assuage the others as appropriate, given the threat- and asset value-based budget considerations. This is a subtle but very important point. Some would-be system vulnerabilities can be eliminated altogether by modifying the business or IT processes. If the value of the asset and the extent of the threat warrant, eliminating a vulnerability is often more effective than developing a set of technical or non-technical controls to mitigate it. Another consideration is how to mitigate or recover from the impact of malicious or harmful activity, either deliberate or inadvertent, that can impact the business. Examples of mitigation practices are developing a recovery or failover capability to deal with Denial of Service incidents, incorporating the public relations team in the security incident response process to help "media spin" a public embarrassment, or creating backups to assuage the loss of or damage to an asset. Architecture Defined Architecture means many things to many people. For the purposes of this report, architecture is a set of principles and directions (a road map) that guides the engineering process and product selection. It includes detailed design; product selection; construction; implementation; support; and management of an organization’s information systems and technology infrastructure.2 is NOT simply an approved product list or a network diagram. Architecture An architecture can be formulated at multiple levels. For example, an organization can define an enterprise-wide architecture that guides all development activities, including information systems and infrastructure development (networks, servers, middleware, etc.). An enterprise-wide architecture helps steer discrete projects towards a desired future state. In this context, architecture enables organizations to develop systems that meet business goals and objectives over a period of time. 20 Source: METASeS, as at http://horseproject.wiki/images/3/38/Secure-System-Development-Life-Cycle.pdf, as on 10th May, 2017. 133 | P a g e Architecture also can refer more specifically to a subnetwork or a specific business system. Such a system-level architecture typically includes a more specific set of goals and requirements that drive the system design. In this discussion, we will refer to system-level security architecture as it applies to a specific business system project. Our focus is on only the Information Security aspects -- the technical and non-technical controls used to achieve the business security goals. In this document, we will spend the majority of time discussing the technical control mechanisms. The line between architecture and system design is often blurry. In its pure form, which is rarely encountered "in the wild", architecture is expressed as a set of goals or requirements. Design, on the other hand, is the integration of the hardware, software, processes, and procedures required to achieve the goals. For example, security architecture may express the goal of restricting perimeter network access, but would not necessarily mandate a specific firewall, which might fall under design’s purview. Academic musing about the split between architecture and design is not important. What is critical is that you express the architecture at some level in terms of specific goals or requirements. Iterative Steps: Practice Makes Perfect We will walk through this phase, like the others, in a linear series of steps. However, note that finalizing the architecture and designing a security solution is often in practice an iterative process, that is, it requires several passes to get it right. The idea behind these repetitions is to catch design level vulnerabilities that can be mitigated or effectively removed through a change in design. For example, a help desk often performs the function of resetting user passwords. This can introduce vulnerabilities into the system if the help desk employees have access to the system tools used to change the passwords. You could permit customers to reset their passwords themselves (with the appropriate authentication processing of course), or provide the help desk with only "reset" capabilities. Such steps would remove the vulnerability outright. In the first iteration, you review the requirements set forth in the previous requirements analysis phase, along with the current enterprise-wide technical architecture or enterprise-wide security architecture and processes. With those items as input, you will begin to formulate the system-level Information Security architecture. Architecture’s Twin Components The architecture will have two components: 1. Technical Controls -- System controls defined in the architecture and enumerated in a system design. Technical controls might include methods such as data redundancy and tools such as Redundant Array of Independent Disks (RAID) to achieve the security goal of data availability, or token-based authentication methods like SecureID cards, to attain the confidentiality goal. 2. Non-Technical Controls -- Controls embodied in processes and procedures. For example: 134 | P a g e • Dual Entry – The requirement of multiple signatures or approvals to allow a sensitive transaction to proceed. • Separation of Duties – The separation out of business functions so that no one individual has sole responsibility for a type of transaction. • Audit Reviews – The review of processes in an attempt to identify malfunctions or inconsistencies in operation. • Awareness Programs – Training courses or internal advertising to help modify potentially harmful end-user behaviours System-Level Architecture Development Formulating system-level security architecture is basically a process of inputs and outputs. In this section, we will illustrate both the traditional architecture development process, and a "fast path" method for meeting some of the stringent time requirements of the new Internet business world. Key Inputs The fundamental security goals are one of the main inputs to the system-level security architecture of a Web or e-Commerce business system. The key inputs to the system-level security architecture derive from the requirements analysis tasks above. They include: Security Goals Assets Threats Activities Current and Future Business Direction Infrastructure External Regulatory Requirements and Corporate Security Policy Vulnerability Management21 Vulnerability management (VM) is the cyclical practice of identifying, classifying, remediating, and mitigating vulnerabilities. This is a broad definition that has implications for corporate or government entities. It is not a new discipline, nor is it a new technology. This vital function has been a normal part of hardening defences and identifying weaknesses to systems, processes, and strategies in the military and in the private sector. With growing complexity in organizations, it has become necessary to draw out this function as a unique practice complete with supporting tools. This has resulted in an important refinement of the definition of VM as a segment of risk management. 21 Source: Information System Security, as at http://www.infosectoday.com/Articles/Intro_Vulnerability_Management.htm, as on 9th May, 2017. 135 | P a g e The Role of Risk Management Risk management seeks to identify the conditions or events under which a loss may occur, and then find the means to address that risk. Addressing risk can take the following forms: Accept the risk; that is, do nothing and let it happen. This is also known as retention. Mitigate the risk; that is, prevent it from happening. Reduce the risk; that is, reduce the consequences by actions such as ensuring against the event. In VM, we look at risks resulting from flaws in systems, processes, and strategies. Figure 1.1 shows the relationship of VM with a risk management program. The purpose is to discover and address risks that result from vulnerabilities under the control or influence of the organization. Other aspects of risk management related to event probability analysis and continuity management are not directly concerned with vulnerabilities. Figure 1.1 Role of vulnerability management in risk management framework. 136 | P a g e VM typically focuses attention on technical software and system configuration vulnerabilities. There are also vulnerabilities related to corporate strategy, economics, and the environment whose detection cannot be automated. They require the attention of a risk manager. These vulnerabilities exist in areas such as business processes, strategies, and supply chains. Every action or plan that a business has could be exploited through design flaws or a lack of adaptability. It is the larger role of the risk manager to recognize and address these challenges. In this book, we discuss primarily technical software and system configuration vulnerabilities; however, some attention is also given to vulnerabilities related to corporate strategy, economics, and the environment. Origins of Vulnerability Management Vulnerability Management has been around for a long time yet few have paid attention to it until recently. The military has long understood and perfected VM through ritual and practice. Inspections of defences from the organization and deployment strategy down to the individual soldier and weapons are the equivalent of audits. The recursive training, equipping, and rearrangement of defences is a form of remediation or hardening. But these activities have not come without an understanding of the enemy. A student of military history can easily recognize how one opponent vanquished another by exploiting a vulnerability or strategic error. These victors are often hailed as geniuses, rather than the losers being seen as incompetent. Consider, for example, the battle of Cannae where Hannibal collapsed his centre line to envelop the Romans so that he could attack from all sides, thereby defeating them. Hannibal is considered a genius for this now-classic tactic. However, one might also see this as a flawed strategy of Varro, one of the Roman consuls at the battle. Varro believed that the Roman army could drive through the centre of Hannibal's front line and drive the entire enemy line to the river at their backs. What he did not consider was the essential discipline for maintaining a uniform front line, which was undeniably a vulnerability. Yet, in the business world we tend to view the failure to be prepared for risk as an example of incompetence. This is especially true when the corporation is generally perceived as being strong, wealthy, and able to dedicate the resources to addressing risk. As an IT discipline, VM has been immature and its users naïve about its application: immature because strong, enterprise-ready technology is only now becoming available, and naïve because the need for a complete, integrated solution with well-defined processes has not been fully recognized. Although military discipline may not seem necessary in a corporate environment, the lack of discipline leads to the one key vulnerability that is not discovered or not remediated, and which may eventually lead to catastrophic losses. Introducing the Security Industry and Its Flaws Not so surprisingly, corporations and government alike have relied on new products to "bolt on" security to their networks. The security industry has focused on selling products and services that require upgrades and maintenance. If there is a security problem that seems to emerge, a vendor has developed a solution. When users started abusing network ports to reach into other host services in a remote network, the industry gave us firewalls. When viruses became a problem, the industry offered us anti-virus software and services. 137 | P a g e When worms like Sasser were found, anti-virus vendors put more anti-virus functionality in the network. When in-house applications became more of a target, application firewalls were offered. Unfortunately, very few of these solutions seem to address the central problem. Most security problems result from a failure to code, patch, configure, or design in a secure manner. This is the military equivalent to a lack of training of the troops, lack of oversight by commanders, and failure to provide adequate equipment. Just as technology vendors continue to provide us with productized solutions, you can hand the troops all the weapons that can be bought but these will not be the targets of your enemy. The product purchase scenario is a strategic failure. It is not my intent to disparage the use of these and other security technologies. They are an important part of an overall security strategy. However, while all of these bad things were happening, few people were focused on identifying and fixing what was exploited, and none of these technologies can fully make up for a failure to use strong passwords or keep shrink-wrapped software patched. The value of most security products in a network comes from their ability to temporarily mitigate risks for which you do not have a more permanent or reliable solution. The anti-virus product is a good idea so long as you get updates quickly and those updates are accurate. When the latest virus comes out, the product should quickly be prepared to stop it until the vendor of the target software supplies a patch. Eventually, the virus will find its way into the organization and around some defences. The important thing is to get a permanent fix in place before that happens. Challenges from Government and Industry The IT department faces many other challenges from the governments of the world. Varying degrees of legislation from one jurisdiction to another create a minefield of legal and operational challenges. Multinational companies are particularly challenged. In some countries, regulators and labor unions treat intrusion detection with suspicion, on the grounds that it may be an invasion of privacy. In other countries, the collection of Internet surfing activity for a particular user is compulsory and must be supplied to the authorities upon request. Vague yet onerous regulations such as SarbanesOxley (SOX) in the United States have resulted in a multitude of security controls that offer little value but considerable expense. This makes active defence of a network in a globally managed package an even bigger challenge because security managers must now differentiate compliance activities from those that bring real security. Add to all of this the industry standards for security controls and the associated certifications and audits. The alphabet grows constantly: SAS 70, SOX § 404, ISO 17799, ISO 27001, PCI, FIPS, HIPAA, GLB, IEEE P1074, EAL. Standards and certification are important, but they often distract us from our most central problems: vulnerable software, architecture, and strategy. There is no long-term substitute for well-written, tested, and properly configured software deployed thoughtfully with solid practices. Sources of Vulnerabilities Software companies are also a real challenge to software buyers everywhere. Their coding practices can stand a lot of improvement, as can their basic designs. Some want to sell more products, so they continue to introduce more functionality without securing what was built before. A new electronic communications protocol or new application using that protocol is developed. 138 | P a g e But they never secure the protocol from the beginning. The vendors also do a fairly poor job of notifying users and issuing patches. The problem is motivational because they see patching as a cost greater than the benefit since no one is paying for the additional development work. In some cases, a vendor is entrenched in the market and customers have few alternatives. The cost of changing software makers can be expensive for a company with thousands of units deployed and hundreds of trained support staff. Example of Flawed Vulnerability Management When we do perform the VM function, it is usually half-heartedly. One company attempted to deploy VM agents throughout the enterprise as an act of payment card industry (PCI) compliance. The auditors told them they should do it, and so they did it without regard to the benefit or the effect. As a result, the only tangible requirement was that the technology be deployed. No one considered what would happen after that. Obvious questions such as "on which hosts do we install the agents?" and "what vulnerabilities do we have to fix first?" were ignored. I refer to this as the check box security strategy. Someone to whom a company has delegated authority provides a checklist of what to fix, and then the company complies. Another obvious problem with this security approach is that a tool that can help address the root cause of so many vulnerabilities would have no official owner. Instead, in my example, the agents and server were installed without anyone to maintain them. No matter how hard you try, maintenance does not happen by itself. Someone has to read the reports, repair or reinstall components or agents, and make sure the reporting server stays healthy. Someone also has to monitor the overall system to make sure that it achieves its objectives. This is the equivalent of deploying a division of troops without a leader. They would be badly coordinated and ineffective. Why Vulnerability Management Is Important For a corporation, resources are quite limited. It can only spend so much on a risk, so an early analysis of risks is certainly important. However, I would argue that there is little excuse for not performing the VM function. It seems difficult to justify spending limited funds on intrusion detection or security event management when VM has not been implemented. Although VM involves more complex processes and systems, the risk profile of a company can look quite different when there are fewer critical vulnerabilities to defend. In this book, you will find far more than a description of the technology and a few tips on how to get it going. You will gain an in-depth understanding of how VM works from both a technology perspective and a process perspective. Neither one is very useful without the other. Technology tools are facilitators of the process. Much time will be spent understanding this. Experience in the uniqueness of your company's environment will bring you to the realization that only those who are very serious about having a strong, secure infrastructure are needed. Anything else is a waste of money and time. You will also gain an understanding of the strategic significance of vulnerabilities and their control. Beyond the concern for a single host or network device, vulnerabilities can exist at other levels that can only be addressed by adjustment to the technology strategy. It is risk management at an organization and industry level, and transcends any technology. 139 | P a g e Ways to Mitigate Overlooked Network Security Risks22 The vast majority of information security incidents aren't caused by highly-sophisticated, unprecedented technological exploitation. In fact, the bulk of security incidents are caused by just ten known security vulnerabilities or humans who fall prey to phishing attacks. Significantly reducing your company's risk of data breach requires organizations to mitigate the most commonly overlooked risks. The breadth of the security field may be responsible for an organization's overlooked vulnerabilities. While one company may be an expert at applying necessary patches, the security policy may be well out-of-date. A competitor may have strong technological safeguards, but sloppy mobile protection. Best practices and regulatory compliance require organizations to take a comprehensive approach to risk management. In this blog, we'll define 10 of the most commonly overlooked security risks and discuss best practices for mitigation. 1. Mobile Devices Mobile devices are a critical tool for worker productivity. A CIOInsight study indicates workers may gain as many as nine hours per week of additional productivity when given access to a smartphone, tablet, or another device. However, these devices can introduce a wide array of risks and vulnerabilities to the enterprise. Some of the most common mobile-related risks can include: 22 Source: Cimcor, as at http://www.cimcor.com/blog/10-smart-ways-to-mitigate-overlooked-networksecurity-risks, as on 9th May, 2017. 140 | P a g e Device theft Communication interception Mobile malware User risks (sharing devices) How to Mitigate Mobile Device Risk: Mobile device management (MDM) technology can improve oversight and the ability to maintain consistent, on-time security updates to mobile devices. Ensure your Acceptable Use Policies include clear guidelines for company and employeeowned mobile devices. Agent-based file integrity monitoring software can enable negative change detection on devices, even if they aren't connected to your company network. Carefully weigh the risks and benefits of a Bring-Your-Own-Device (BYOD) policy and whether it's worth implementation at your organization. 2. Portable Storage Devices Portable storage devices like USB drives have the potential to both leak and introduce data to your network. While many organizations have chosen to introduce policies which prohibit the use of USB flash drives and other portable storage devices to mitigate risks, some are still reliant upon these business tools. If your organization is still using portable storage devices, it's wise to consider better controls around these items or an alternative like cloud-based file sharing. How to Mitigate Portable Storage Device Risk Consider turning off ports in your desktops to completely prevent use. This can be accomplished with Windows Active Directory. Provide employees with alternatives to portable storage devices for data-sharing needs such as cloud-based file sharing options. Address portable storage devices in your security policy; include clear guidelines for use or the complete prohibition of use. 3. Poor Password Management A shocking number of passwords are still set as "admin" or "default" due to poor password governance and control. These vulnerabilities can occur when IT professionals vow to change passwords "later" and fail to follow-up. Other forms of poor organizational control, such as minimal password standards or infrequent password changes, can result in network security risks. How to Mitigate Poor Password Management Risk: Implement technical safeguards to enforce appropriate passwords and changes. Address policies and penalties for employee password sharing in your security policy. Fully encrypt all stored passwords in compliance with PCI-DSS standards. 141 | P a g e 4. Poor Authentication Requirements Single-factor authentication can allow unauthorized access to go undetected for long periods of time. While most security managers are familiar with the basics of access authentication— knowledge of credentials and possession of a known device—additional factors may be necessary for adequate security. The 2016 Verizon Data Breach Investigation Report (DBIR) indicates a shocking number of data breaches occur after criminals gain access with credentials either stolen through phishing or hacked with brute force. Think of authentication as a critical sidekick to better password management which can help detect unauthorized access to an authorized account. How to Mitigate Poor Authentication Requirements: Implement, at a minimum, a two-factor authentication for users to gain successful access. Consider adding time and location of access as additional authentication factors. 5. Default Software Installations Vulnerabilities in systems and applications can occur in both vendor-produced and home-grown IT solutions. Failing to update software can maximize risks. The ten most common technical vulnerabilities accounted for over 85% of data breaches in the past year. It's crucial to shift towards an active model of identifying and remediating threats based on known vulnerabilities in your software configurations. How to Mitigate Application Risk: Deploy all updates from vendors to your software immediately. Actively identify and remediate risks in both vendor-supplied and homegrown applications. Follow appropriate change control procedures every time configurations are changed or updated. 6. Missing Patches A single missing patch can weaken your entire network, leaving you vulnerable to attack. If your company's data ecosystem is complex, it can be easy to lose control of patch updates and let patches on utility servers go well out-of-date. However, this can introduce a significant vulnerability that organizations simply can't afford. How to Mitigate the Risk of Missing Patches: Apply patch updates regularly in accordance with PCI requirements. Continue monitoring your critical files for negative changes during scheduled patch updates, instead of turning off file integrity monitoring software during update periods. 7. Insider Threats 142 | P a g e In a recent TechRepublic poll, 76% of pros noted that "insider threats" are their biggest network security concern. In most cases, insider risks originate from poor knowledge or carelessness which can lead to human error or ignored policies and procedures. More rarely, insiders with malicious intent can wreak havoc due to first-hand knowledge of system vulnerabilities and technical workarounds. Examples of organizational factors that may put you at risk of realized insider threats can include: Minimal training, Poor new hire screening, Excessive user access, and Unchecked administrative "super" users. How to Mitigate Insider Threats: Implement behaviorally-driven training and metrics to measure the results of your awareness programs. Create comprehensive access governance policies to ensure users have the minimum degree of necessary access. Systemize daily review of your audit lots and log review and ensure your logs cannot be edited by super users. 8. Poor Configuration Choices In many cases, default configurations can introduce a great deal of risk into network security. An expert review of your firewall rule bases could reveal a number of vulnerabilities because they aren't a good match for your organization's security needs. How to Mitigate Poor Configuration: Ensure your security policy is comprehensive Use policy to guide firewall configuration rule bases. 9. Insufficient Policy Without a comprehensive security policy, it is difficult to control and enforce positive behaviors in an enterprise. Your policy should be a guiding force behind your IT and employee-led efforts to mitigate risks. Per PCI, "All employees should be aware of the sensitivity of cardholder data and their responsibilities for protecting it." If your policy leaves any room for questions, it's probably long overdue for an update. The following risk mitigation recommendations are influenced by PCI compliance standards, which represent best practices even for organizations that are not required to comply. How to Mitigate Policy Risk: Review and revise your policy at least once per calendar year. 143 | P a g e Develop daily, weekly, and monthly security procedures, and assign each of these responsibilities clearly to capable personnel. Address acceptable usage of computers, mobile, and other devices. Define the organization-wide responsibility to protect information for all employees, and ensure every employee is aware of this responsibility. 10. Infrequent File Integrity Monitoring PCI requirements 10.5.5. and 11.5 require file integrity monitoring at least once per week. However, failing to monitor more frequently and certain forms of file integrity monitoring can fail to mitigate your network vulnerabilities. Agentless file integrity monitoring may only observe changes in throughput, which can neglect the detection of negative changes on certain network devices. Going a full week or longer between scans can allow unauthorized access to your network to go undetected for days or more. As the DBIR reminds us, 82% of data breaches are complete in a minutes or less. Without real-time file integrity monitoring software, your organization could fail to notice you're under attack until it's far too late to stop anything. How to Mitigate Integrity-Based Risks: Implement real-time, agent-based file integrity monitoring software. Consider a solution which allows full, real-time remediation of negative changes. Get the Fundamentals Right Many of the most commonly-overlooked network vulnerabilities are relatively simple. Out-of-date patches and default passwords can place companies at risk for a successful information security attack. By using compliance, policy, and best-of-class security technologies to guide your security program, you can approach vulnerabilities with the systemic ability to search and destroy risks. Activity 6 Provide an example of one risk that should be mitigated during system design. 144 | P a g e Activity 6 145 | P a g e Activity 6 Data correlated from Metasploit and Microsoft Security Patch Information (covering 16 months between mid-2013 to late 2014) found that the points below could assist in mitigating up to 95% of exploits, which affect Windows, Internet Explorer, and Microsoft Office23. 1. Require administrators to use standard accounts unless actively performing an administrative task. Many organizations do not look at elevated privileges as a security threat despite the fact many breaches are designed to exploit users running as administrator. Implementing any type of privileged desktop elevation solution which permits a standard user to perform a limited number of administrative tasks would greatly improve security. Such a solution would allow administrators to define which applications or tasks can run with elevated privileges while preventing unapproved software installs, accidental execution of malicious software/scripts, and browsing the web when a user is actively logged on as an administrator. 2. Run the latest major version of Microsoft Windows, Office, and Internet Explorer Experience has taught us that identifying and patching vulnerabilities is a fundamental aspect to security. Most malware leverages vulnerabilities to exploit systems. Oddly what is also very effective is running the latest major versions, even without patching. This is not to suggest you should not patch but point out that Windows 8 is essentially Windows 7 with all the security patches rolled in at the time of release. The same concept applies to Office 2013 vs. Office 2010 or Internet Explorer 11 vs. Internet Explorer 10. 3. Contain and alert on what is leaving your network (Egress filtering) Monitoring and/or denying certain outbound traffic is not so much about preventing a breach, rather, it’s focused on containment of sensitive data after a breach has occurred. There are numerous examples where custom malware traffic is designed to communicate over port 443 and 23 Source: Windows IT Pro, as at http://windowsitpro.com/security/4-steps-mitigate-95-known-vulnerabilities 146 | P a g e something as simple as an authenticated web proxy could prevent this traffic from leaving the network. Savvy malware writers have been known to encrypt data leaving networks, making it difficult to determine the content of the data, thus, the value in data analysis lies in determining traffic patterns, sources and destinations to limit the amount of information lost. 4. Implement Multi-factor Authentication “Death to passwords” is a rally cry we have heard for almost a decade. Although it is unlikely that a large corporate network could completely eliminate passwords, we can significantly reduce password vulnerability by introducing additional factors for authentication. What multi-factor authentication adds is strength that a compromised password alone is not valuable as they do not have the required token to successfully logon. There are numerous options when it comes to multi-factor authentication including OTP (One Time Password), RFID, Smart Card, Fingerprint Reader, or Retina Scanner. Although a layperson may not recognize the term Multi-factor authentication, it is already used by most adults in the US today. The ATM card in your wallet that also has a pin number is the perfect example of two factor authentication used to secure a valuable asset. Staying up-to-date on security patches, limiting the use of administrator level rights, and implementing a multi-factor authentication protocol into your environment could assist in mitigating up to 95% of exploits based on the data evaluated. These measures, along with a good Egress filtering strategy, in case you are ever hacked, are the most effective ways to reduce the potential of being breached. No matter what approach your organization chooses to take, the most important thing you can do is continuously monitor and review your security practices. Attackers are always evolving and refining their methods, so, you too must be diligent and take the steps necessary to ensure you are properly protected. When discussing network security, the three common terms used are as follows: Vulnerability—A weakness that is inherent in every network and device. This includes routers, switches, desktops, servers, and even security devices themselves. Threats—The people eager, willing, and qualified to take advantage of each security weakness, and they continually search for new exploits and weaknesses. Attacks—The threats use a variety of tools, scripts, and programs to launch attacks against networks and network devices. Typically, the network devices under attack are the endpoints, such as servers and desktops. The sections that follow discuss vulnerabilities, threats, and attacks in further detail. 147 | P a g e Vulnerabilities Vulnerabilities in network security can be summed up as the “soft spots” that are present in every network. The vulnerabilities are present in the network and individual devices that make up the network. Networks are typically plagued by one or all of three primary vulnerabilities or weaknesses: Technology weaknesses Security policy weaknesses Configuration weaknesses Technological Weaknesses Computer and network technologies have intrinsic security weaknesses. These include TCP/IP protocol weaknesses, operating system weaknesses, and network equipment weaknesses. Table 1-3 describes these three weaknesses. Configuration Weaknesses 148 | P a g e Network administrators or network engineers need to learn what the configuration weaknesses are and correctly configure their computing and network devices to compensate. Table 1-4 lists some common configuration weaknesses. Security Policy Weaknesses Security policy weaknesses can create unforeseen security threats. The network can pose security risks to the network if users do not follow the security policy. Table 1-5 lists some common security policy weaknesses and how those weaknesses are exploited. 149 | P a g e Threats There are four primary classes of threats to network security, as Figure 1-12 depicts. The list that follows describes each class of threat in more detail. 150 | P a g e Unstructured threats—Unstructured threats consist of mostly inexperienced individuals using easily available hacking tools such as shell scripts and password crackers. Even unstructured threats that are only executed with the intent of testing and challenging a hacker’s skills can still do serious damage to a company. For example, if an external company website is hacked, the integrity of the company is damaged. Even if the external website is separate from the internal information that sits behind a protective firewall, the public does not know that. All the public knows is that the site is not a safe environment to conduct business. Structured threats— Structured threats come from hackers who are more highly motivated and technically competent. These people know system vulnerabilities and can understand and develop exploit code and scripts. They understand, develop, and use sophisticated hacking techniques to penetrate unsuspecting businesses. These groups are often involved with the major fraud and theft cases reported to law enforcement agencies. External threats—External threats can arise from individuals or organizations working outside of a company. They do not have authorized access to the computer systems or network. They work their way into a network mainly from the Internet or dialup access servers. Internal threats—Internal threats occur when someone has authorized access to the network with either an account on a server or physical access to the network. According to the FBI, internal access and misuse account for 60 percent to 80 percent of reported incidents. 151 | P a g e As the types of threats, attacks, and exploits have evolved, various terms have been coined to describe different groups of individuals. Some of the most common terms are as follows: Hacker—Hacker is a general term that has historically been used to describe a computer programming expert. More recently, this term is commonly used in a negative way to describe an individual who attempts to gain unauthorized access to network resources with malicious intent. Cracker—Cracker is the term that is generally regarded as the more accurate word that is used to describe an individual who attempts to gain unauthorized access to network resources with malicious intent. Phreaker—A phreaker is an individual who manipulates the phone network to cause it to perform a function that is normally not allowed. A common goal of phreaking is breaking into the phone network, usually through a payphone, to make free long-distance calls. Spammer—A spammer is an individual who sends large numbers of unsolicited e-mail messages. Spammers often use viruses to take control of home computers to use these computers to send out their bulk messages. Phisher—A phisher uses e-mail or other means in an attempt to trick others into providing sensitive information, such as credit card numbers or passwords. The phisher masquerades as a trusted party that would have a legitimate need for the sensitive information. White hat—White hat is a term used to describe individuals who use their abilities to find vulnerabilities in systems or networks and then report these vulnerabilities to the owners of the system so that they can be fixed. Black hat—Black hat is another term for individuals who use their knowledge of computer systems to break into systems or networks that they are not authorized to use. Attacks Four primary classes of attacks exist: Reconnaissance Access Denial of service Worms, viruses, and Trojan horses The sections that follow cover each attack class in more detail. Reconnaissance Reconnaissance is the unauthorized discovery and mapping of systems, services, or vulnerabilities (see Figure 1-13). It is also known as information gathering and, in most cases, it precedes an actual access or denial-of-service (DoS) attack. Reconnaissance is somewhat analogous to a thief casing a neighbourhood for vulnerable homes to break into, such as an unoccupied residence, easy-to-open doors, or open windows. 152 | P a g e Access System access is the ability for an unauthorized intruder to gain access to a device for which the intruder does not have an account or a password. Entering or accessing systems to which one does not have authority to access usually involves running a hack, script, or tool that exploits a known vulnerability of the system or application being attacked. Denial of Service (DoS) Denial of service implies that an attacker disables or corrupts networks, systems, or services with the intent to deny services to intended users. DoS attacks involve either crashing the system or slowing it down to the point that it is unusable. But DoS can also be as simple as deleting or corrupting information. In most cases, performing the attack simply involves running a hack or script. The attacker does not need prior access to the target because a way to access it is all that is usually required. For these reasons, DoS attacks are the most feared. 153 | P a g e Worms, Viruses, and Trojan Horses Malicious software is inserted onto a host to damage a system; corrupt a system; replicate itself; or deny services or access to networks, systems or services. They can also allow sensitive information to be copied or echoed to other systems. Trojan horses can be used to ask the user to enter sensitive information in a commonly trusted screen. For example, an attacker might log in to a Windows box and run a program that looks like the true Windows logon screen, prompting a user to type his username and password. The program would then send the information to the attacker and then give the Windows error for bad password. The user would then log out, and the correct Windows logon screen would appear; the user is none the wiser that his password has just been stolen. Even worse, the nature of all these threats is changing—from the relatively simple viruses of the 1980s to the more complex and damaging viruses, DoS attacks, and hacking tools in recent years. Today, these hacking tools are powerful and widespread, with the new dangers of selfspreading blended worms such as Slammer and Blaster and network DoS attacks. Also, the old days of attacks that take days or weeks to spread are over. Threats now spread worldwide in a matter of minutes. The Slammer worm of January 2003 spread around the world in less than 10 minutes. The next generations of attacks are expected to spread in just seconds. These worms and viruses could do more than just wreak havoc by overloading network resources with the amount of traffic they generate, they could also be used to deploy damaging payloads that steal vital information or erase hard drives. Also, there is a strong concern that the threats of tomorrow will be directed at the very infrastructure of the Internet. Vulnerability Analysis Before adding new security solutions to an existing network, you need to identify the current state of the network and organizational practices to verify their current compliance with the requirements. This analysis also provides you with the opportunity to identify possible improvements and the potential need to redesign a part of the system or to rebuild a part of the system from scratch to satisfy the requirements. This analysis can be broken down into the following steps: 1. Policy identification 2. Network analysis 3. Host analysis The remainder of this chapter looks at each of these steps in more depth and at some analysis tools. Policy Identification If a security policy exists, the designer should analyze it to identify the security requirements, which will influence the design of the perimeter solution. Initially, the designer should examine two basic areas of the policy: 154 | P a g e The policy should identify the assets that require protection. This helps the designer provide the correct level of protection for sensitive computing resources and to identify the flow of sensitive data in the network. The policy should identify possible attackers. This gives the designer insight into the level of trust assigned to internal and external users, ideally identified by more-specific categories such as business partners, customers of an organization, and outsourcing IT partners. The designer should also be able to evaluate whether the policy was developed using correct riskassessment procedures. For example, did the policy development include all relevant risks for the organization and not overlook important threats? The designer should also reevaluate the policy mitigation procedures to determine whether they satisfactorily mitigate expected threats. This ensures that the policy, which the designer will work with, is current and complete. Organizations that need a high level of security assurance will require defense-in-depth mechanisms to be deployed to avoid single points of failure. The designer also needs to work with the organization to determine how much investment in security measures is acceptable for the resources that require protection. The result of policy analysis will be as follows: The evaluation of policy correctness and completeness Identification of possible policy improvements, which need to be made before the security implementation stage Network Analysis Many industry best practices, tools, guides, and training are available to help secure network devices. These include tools from Cisco, such as AutoSecure and Cisco Output Interpreter, and from numerous web resources. Third-party resources include the U.S. National Security Agency (NSA) Cisco Router Security Recommendation Guides and the Center for Internet Security (CIS) Router Audit Tool (RAT) for auditing Cisco router and PIX Security Appliance configuration files. Cisco AutoSecure The Cisco AutoSecure feature is enabled from a Cisco IOS Security command-line interface (CLI) command, as shown in Table 1-6. AutoSecure enables rapid implementation of security policies and procedures to ensure secure networking services. It enables a “one-touch” device lockdown process, simplifying the security configuration of a router and hardening the router configuration. This feature simplifies the security process, thus lowering barriers to the deployment of critical security functionality. 155 | P a g e Cisco Output Interpreter The Cisco Output Interpreter (see Figure 1-28) is a troubleshooting tool that report potential problems by analyzing supported show command output. The Output Interpreter is available at the Cisco website to users with a valid Cisco.com. 156 | P a g e Output Interpreter supports the following functionality: Displays show command output from a router, switch, or PIX Security Appliance. A list of supported show commands is available at the Output Interpreter site. Displays error messages generated by a router, switch, or PIX Security Appliance. The error or log messages can be copied and pasted from a router, switch, or PIX Security Appliance into the Output Interpreter. Decodes and analyzes a router or switch stack trace for any possible bugs. Copy and paste the show version command output followed by traceback or stack trace and alignment data. Can convert the apply, conduit, and outbound statements of a PIX Security Appliance configuration to equivalent access-list statements. Copy and paste show tech-support or write terminal command output of the PIX Security Appliance. Decodes and analyzes the Configuration Register. Copy and paste the show version or show tech-support command output into the Output Interpreter. Figure 1-29 shows an example of the output of the Output Interpreter. 157 | P a g e Integrate applicable information security requirements, controls, processes, and procedures into ICT system and application design specifications according to established requirements Acquisition / Development Phase – – Risk Assessment – analysis that identifies the protection requirements for the system through a formal risk assessment process. This analysis builds on the initial risk assessment performed during the Initiation phase, but will be more in-depth and specific. – Security Functional Requirements Analysis – analysis of requirements that may include the following components: (1) system security environment, (i.e., enterprise information security policy and enterprise security architecture) and (2) security functional requirements – Security Assurance Requirements Analysis – analysis of requirements that address the developmental activities required and assurance evidence needed to produce the desired level of confidence that the information security will work correctly and effectively. The analysis, based on legal and functional security requirements, will be used as the basis for determining how much and what kinds of assurance are required. – Cost Considerations and Reporting – determines how much of the development cost can be attributed to information security over the life cycle of the system. These costs include hardware, software, personnel, and training – Security Planning – ensures that agreed upon security controls, planned or in place, are fully documented. The security plan also provides a complete characterization or description of the information system as well as attachments or references to key documents supporting the agency’s information security program (e.g., configuration management plan, contingency plan, incident response plan, security awareness and training plan, rules of behavior, risk assessment, security test and evaluation results, system interconnection agreements, security authorizations/accreditations, and plan of action and milestones). – Security Control Development – ensures that security controls described in the respective security plans are designed, developed, and implemented. For information systems currently in operation, the security plans for those systems may call for the development of additional security controls to supplement the controls already in place or the modification of selected controls that are deemed to be less than effective. – Developmental Security Test and Evaluation – ensures that security controls developed for a new information system are working properly and are effective. Some types of security controls (primarily those controls of a non-technical nature) cannot be tested and evaluated until the information system is deployed—these controls are typically management and operational controls. 158 | P a g e – Other Planning Components – ensures that all necessary components of the development process are considered when incorporating security into the life cycle. These components include selection of the appropriate contract type, participation by all necessary functional groups within an organization, participation by the certifier and accreditor, and development and execution of necessary contracting plans and processes. Organizations today, from small businesses with Web and email access to multisite global enterprises, face increasingly sophisticated attacks carried out over the Internet. Once an attacker gains access to internal networks, the damage that ensues can be catastrophic, resulting in data disclosures and destruction, business disruption and damage to an organization's reputation. Even with solid perimeter defences (e.g., firewalls, intrusion detection/prevention systems, VPNs and so on), hardened systems and endpoint protection, security breaches still occur. The question is when and how will these security breaches happen?24 The attack surface of an IT environment changes constantly. As new computers and devices are installed, operating systems and applications are upgraded and firewall rules are changed, causing new vulnerabilities to be introduced. One way to find out how attackers could breach network defences and damage internal servers, storage systems and endpoints -- and the data they hold and transfer -- is to discover and close those vulnerabilities. That's where vulnerability management tools come into play. What is vulnerability management? Vulnerability management is a continuous process of discovering, prioritizing and mitigating vulnerabilities in an IT environment. Although vulnerability management tools vary in strength and feature sets, most include the following: Discovery: The process of identifying and categorizing every asset in a networked environment and storing attributes in a database. This phase also includes discovering vulnerabilities associated with those assets. Prioritization: The process of ranking known asset vulnerabilities and risk. Vulnerabilities are assigned a severity level, such as from 1 to 5, with 5 being the most critical. Some systems rank vulnerabilities as low, medium and high. Remediation/Mitigation: The system provides links to information about each vulnerability discovered, which includes recommendations for remediation and vendor patches, where applicable. Some vendors maintain their own vulnerability intelligence database information; others provide links to third-party resources such as The MITRE Corporation's Common Vulnerabilities and Exposures database, the Common Vulnerability Scoring System and/or the SANS/FBI Top 20, to name a few. 24 Source: tech Target, as at http://searchsecurity.techtarget.com/feature/Introduction-to-vulnerabilitymanagement-tools, as on 9th May, 2017. 159 | P a g e Organizations tackle the most severe vulnerabilities first and work their way down to the least severe as time and resources permit. Some vulnerabilities don't pose a serious threat to the organization and may simply be accepted, which means they are not remediated. In other words, the risk is judged to be less than the costs of remediation. How do vulnerability management tools work? Vulnerability management tools come in three primary forms: stand-alone software, a physical appliance with vulnerability management software or a cloud-hosted service. A customer uses a Web-based interface to configure the product to scan a range of Internet Protocol (IP) addresses -both IPv4 and IPv6 -- the entire network or URL, and may select other criteria to inspect, such as the file system, configuration files and/or the Windows registry. The more criteria and the larger the number of IPs, the longer a scan takes to complete. Most vulnerability management tools provide preconfigured scans, and an administrator can modify those templates to save customized scans that run on demand or on a scheduled basis. Note: Highly penetrating scans that assess "hard-to-reach" areas of a network may require an administrator to temporarily modify a firewall to get the most detailed results, although some vendors claim their products can perform complete scans without any such firewall modifications. A comprehensive vulnerability scanner should be able to perform continuous inventorying of wired and wireless devices, operating systems, applications including Web apps, ports, services, protocols, as well as virtual machines and cloud environments. Vulnerability management tools may perform authenticated and unauthenticated vulnerability scans. An unauthenticated scan does not require administrative credentials and focuses on basic issues, such as open ports and services, identity of operating systems and so on. Authenticated scans typically require admin credentials and are more intense, and they may negatively impact a system or network. Although authenticated scans must be used cautiously, usually outside of peak usage hours, they reveal more vulnerabilities than unauthenticated ones. When a vulnerability management tool is put in place, the initial scan that's run should be as complete as possible. This also serves to establish a baseline. Subsequent scans then show trends and help administrators understand the security posture of the environment over time. Most vulnerability management products provide detailed trend analysis reports and charts for display on the console or in print for distribution to managers and executives. Some of these products also include exploit software that's used as a penetration test tool. When vulnerabilities are exposed, an administrator can use the exploit software to see how an attacker could exploit the vulnerability without disrupting network operations. A vulnerability management tool must be used regularly to be effective. Like antivirus products, the data gathered during scans is only as good as the last time it was updated. This means daily scans for most organizations; although small environments or those whose critical assets are not exposed to the Internet may find a weekly scan sufficient. 160 | P a g e Who needs vulnerability management tools? Organizations of all sizes -- from small to midsize businesses (SMBs) to enterprises -- with access to the Internet can benefit from vulnerability management. Customers from nearly every industry and vertical niche use vulnerability management, including education, banking and financial services, government, healthcare, insurance, manufacturing, retail (bricks-and-mortar and online), technology and many more. How are vulnerability management tools sold? Vulnerability management products may be sold as software-only products, a physical appliance with vulnerability management software or as a cloud-hosted service. When purchasing vulnerability management software, customers can expect to pay either an upfront cost and/or licensing and ongoing maintenance fees. The same applies to a physical appliance and software combo, and in this case, the customer also pays for the initial cost of the appliance. Some vendors offer appliance licensing, just like software, to enable organizations to treat the entire purchase as operational expenditure rather than capital expenditure. A cloud-hosted service or software as a service offering is typically sold as an annual subscription that includes unlimited scanning. Vendor cloud pricing varies, and may be based on the number of users, IPs -- either active only or total scanned -- and/or agents deployed. Customers can save money by using services that charge only by active IP, which enables them to scan all IPs on a network, but pay only for those currently in use. Even the smallest of organizations (i.e., those with less than 25 users) need some type of vulnerability management tool, but it's a critical part of a sound security posture for SMBs and enterprises. For organizations that must meet compliance measures, such as HIPAA, Gramm-LeachBliley and PCI DSS, vulnerability management is required. National Security Agency (NSA) Cisco Router Security Configuration Guides The Router Security Configuration Guide (RSCG) contains principles and guidance for secure configuration of IP routers, with detailed instructions for Cisco Systems routers (http://www.nsa.gov/snac/routers/cisco_scg1.1b.pdf). The RSCG was used extensively in the development of the Cisco Router Security course. This guide was developed in response to numerous questions and requests for assistance received by the NSA System and Network Attack Center (SNAC). The topics covered in the guide were selected on the basis of customer interest, community consensus, and the SNAC’s background in securing networks. The RSCG is a large, detailed, yet readable and accessible document. It is supplemented with an Executive Summary Card, a quick checklist for securing your Cisco router. Routers direct and control much of the data flowing across computer networks. The RSCG provides technical guidance intended to help network administrators and security officers improve the security of their networks. Using the information presented here, you can configure your routers to control access, resist attacks, shield other network components, and even protect the integrity and confidentiality of network traffic. 161 | P a g e The goal for this guide is a simple one: improve the security provided by routers on U.S. government operational networks. The RSCG document is only a guide to recommended security settings for IP routers, particularly routers running Cisco IOS Software Release 11 and 12. It is not meant to replace well designed policy or sound judgment. The guide does not address site-specific configuration issues. Care must be taken when implementing the security steps specified in this guide. Ensure that all security steps and procedures chosen from this guide are thoroughly tested and reviewed prior to implementing them on an operational network. Cisco IOS XR Software Cisco IOS XR Software, a new member of the Cisco IOS family, is a unique self-healing and selfdefending operating system designed for always-on operation while scaling system capacity up to 92 Tbps. Cisco IOS XR powers the Cisco Carrier Routing System, enabling the foundation for network and service convergence today while providing investment protection for decades to come. Cisco Router Audit Tool (RAT) The CIS RAT is based on the CIS Benchmark for Cisco IOS routers, a consensus-based best practice guideline for hardening Cisco routers. Version 2.2 of the RAT tool can be used to score both Cisco IOS routers and PIX Security Appliances. The RAT is available for the Windows or UNIX operating systems. Example 1-1 shows a sample RAT output display. The RAT downloads configurations of devices to be audited (optionally) and then checks them against the settings defined in the benchmark. 162 | P a g e For each configuration examined, the RAT produces a report listing the following: A list of each rule checked with a pass/fail score A raw overall score A weighted overall score (1–10) A list of commands that will correct problems identified The RAT produces a composite report listing all rules (settings) checked on all devices (and an overall score) and recommendations for improving the security of the router, as shown in Figure 1-30. 163 | P a g e Host Analysis The hosts that are on the network need to be considered when designing a network security solution. Determining the role in the network of each host will help to decide the steps that will be taken to secure it. The network could have many user workstations, and multiple servers that need to be accessed from both inside and outside of the network. The types of applications and services that are running on the hosts need to be identified, and any network services and ports that are not necessary should be disabled or blocked. All operating systems should be patched as needed. Antivirus software should be installed and kept current. Some servers may be assigned static routable IP addresses to be accessible from the Internet. These hosts in particular should be monitored for signs of malicious activity. Many tools are available to test host security. Most tools have been developed on a UNIX or Linux platform, and some of them have now been ported to other operating systems. Two of the most common tools are as follows: Network Mapper (Nmap)—Nmap is a popular free tool used for security scanning and auditing. It can rapidly perform a port scan of a single host or a range of hosts. Nmap was originally written to be run on UNIX systems, and it is now available for use on Microsoft Windows platforms, as shown in Figure 1-31. Nessus—Nessus is a vulnerability scanner that is available for UNIX and Microsoft Windows platforms. New vulnerability testing capabilities can be added to Nessus through the installation of modular plug-ins. Nessus includes a built-in port scanner, or it can be used along with Nmap. When the Nessus scan is finished, a report is created. This report displays the results of the scan and provides steps to mitigate vulnerabilities. 164 | P a g e Analysis Tools Many tools are available to help to determine vulnerabilities in endpoint devices, such as network hosts and servers. You can obtain these tools from either the company that creates the operating system or a third party. In many cases, these tools are free. The sections that follow describe some of the most commonly used analysis tools. Knoppix STD Knoppix Security Tools Distribution (STD) is a Linux LiveCD distribution that contains many valuable security tools. The LiveCD is a bootable CD-ROM that contains the Linux operating system, along with software applications, that can be run from memory without installation on the hard drive. After the LiveCD is ejected from the CD-ROM drive, the system can be rebooted to return to the original operating system. Knoppix STD contains many useful features, such as the following: Encryption tools Forensics tools Firewall tools Intrusion detection tools Network utilities Password tools Packet sniffers Vulnerability assessment tools Wireless tools Many additional versions of LiveCD are available. If one distribution does not support a particular system or piece of hardware, it might be necessary to try another distribution. Most LiveCD releases are available as free downloads that the end user can burn to a CD. 165 | P a g e Microsoft Baseline Security Analyzer You can use the Microsoft Baseline Security Analyzer (MBSA) to scan hosts running Windows 2000, Windows XP, and Windows Server 2003 operating systems to determine potential security risks. MBSA scans for common system misconfigurations and missing security updates. MBSA includes both a graphical interface and a CLI that can perform local or remote scans. After a system scan, the MBSA provides a report outlining potential vulnerabilities and the steps required to correct them. This tool is available as a free download from Microsoft. Architecture/Design Considerations There are two sets of architecture/design considerations: 1. First order, business-focused considerations 2. Second order, technical considerations The output of the first set of discussions, completed in the requirements phase, will provide the grist for another series of more technical discussions that cover the second-order architectural/design considerations. These include: • Business and IT Operational Considerations – - Characterization of business operational and IT operational items that may impact the security architecture. For example: - How will new customers be set up and by whom? - How will users of the system be updated (e.g., password resets, changes in access rights), or removed from the system? - Will disparate systems be maintained, or are plans in place to further consolidate the types of systems that are operational within the IT environment? - Does the organization’s security philosophy support central security administration and management, or is a decentralized approach preferred? • System Use Considerations – Who and what will use the system, and when, where, and why will the system be used? For example: - Who are the end users of the system (novice or expert user, employee or non-employee, etc.)? - From where will users be accessing the system (home, office, company network, within the country or across country borders, etc.)? - When will users be accessing the system? 166 | P a g e • Technical Environment/Architecture – Characterization of the current IT infrastructure that will either help or impede security. • Current Enterprise Security Architecture - The current and future direction of the organization relative to security. For example, a common enterprise security architecture goal is to externalize the user authentication processing from applications to enable easier administration of user rights and privileges across multiple systems. Thus, the system architecture team needs to consider if and how this should be accomplished for the system level security architecture. Further, many organizations are establishing a set of infrastructure security services – PKI, or proxies – that the system architecture team may want to – or be forced to – take advantage of. These second-order discussions need to include mid-level business management as well as the applications development, IT infrastructure and security teams. The system-level security architecture will flow out of these second-order discussions, and should include the specific prioritized goals and requirements of the architecture. At this level, the output will likely include an initial top-level design, and also should include non-technical process and procedural controls (often identified in a Concept of Operation (CONOP)). Walkthrough Bench Test A best practice recommendation at this point in the architecture/design process is to go engage the architecture and mid-level business management teams in a bench test -- sometimes referred to as a walkthrough. The teams review the theory behind the system-level security architecture and top level design. They apply a series of scenarios against the proposed architecture -- technical and nontechnical controls -- to see if they achieve the desired goals prior to moving onto the detailed design. Of course, effective security also requires sound design, construction, testing, implementation, maintenance and, in particular, training. In addition, since the new system will likely run across existing infrastructure, the architecture team will necessarily have to consider whether the current infrastructure provides adequate baseline controls for the new system. In our experience, many organizations lack appropriate technical security standards and configuration procedures that serve as the basis for a secure infrastructure. Like a house built on a shaky foundation, an application hosted on a vulnerable infrastructure is at risk. Thus, you must also include architectural requirements for the associated infrastructure, even for a system-level security architecture focused on a single application. Baseline Best Practice Template for Internet Speed One of the most precious business commodities in the new Internet world is speed. The ability to get to market more quickly with a business system than a competitor – "time to market" -- can provide a decided competitive advantage. 167 | P a g e Thus, the notion that "speed matters" is very appropriate to the new Internet business models. However, the traditional architecture and design process can be a lengthy one, with cycle times that are longer than many Internet business endeavours can endure. Therefore, many best practice organizations adopt new architecture development process models that improve their ability to quickly deploy new system-level architectures in general and system-level security architecture specifically. We recommend the use of best-practice base line templates. Figure 8 shows how an organization can develop and use baseline best-practice architectures to speed up the process. The premise of this approach is that there are a relatively small number of different types of Web based systems. Further, similar types of business systems share a set of similar information protection requirements. These requirements can be enumerated and captured as a predefined set of "best practice" system-level security architecture/design templates. Thus, when business units decide to develop a new business system, the first hurdle for the security team is to decide what "type" of business system it will be, and to choose the template that it most closely matches. Then the first-order and even the second-order discussions can be focused on where the new business application diverges from the baseline template -- this delta is often called the GAP in consulting circles. The first facilitated discussions focus on the gap between the typical security goals, threats, assets, vulnerabilities, etc. captured in the template, and the unique requirements of the application at hand. Similarly, the secondary set of discussions would use this gap information to provide the basis for a rapid development of a new system-level security architecture/design. To use a homebuilding analogy again, this process is similar to the use of model homes. Homebuyers can pick a style, customize just a few components, and move into their development tract in no time. Using baseline best practices also helps you achieve the legal or regulatory standard of due care in protecting company-owned assets, and assets in which the company plays a custodial role. By benchmarking the baseline templates against the industry and continuing to evolve them to meet best practice, the organization is taking prudent and responsible steps, which are typically part of the due care considerations that regulators and courts review. Finally, do not forget to appropriately size the infrastructure to meet the overall performance goals of your applications. Performance is especially important when dealing with an Internet environment. User calls to Web servers usually place a great load on the system. Turning on the security features, for example, the logging services, will negatively affect system performance by taking up a lot of system cycles. Encryption services for securing data transmitted over the Web are notorious for being resource hogs. The underlying hardware infrastructure may not have been adequately sized in order to take security programs into account. 168 | P a g e Architecture and Design Tasks We now again pick up the discussion of key architecture and design tasks. The following tasks are discussed: • Create System-Level Security Architecture • Perform Architecture Walkthrough • Create System-Level Security Design • Perform Design Review • Educate Development Teams on How to Create a Secure System • Design End-User Training Awareness Measures • Design a Security Test Plan • Assess and Document How to Mitigate Key Application and Infrastructure Vulnerabilities Execute enterprise and ICT system or application security policies Procedures should contain sufficient detail to be executable25 Many organizations have those one or two superstar tech geniuses who know how to do everything. While it is good to have such talent on your staff, it ultimately represents a risk to your organization if security procedures are not put in place. What would be the response if your superstar is out on vacation when his or her knowledge of how to do something is suddenly needed? Avoid such circumstances by developing security procedures to define the how, where and when things get accomplished. Beware to avoid developing procedures that rely on expert knowledge as a foundation to execute the procedure, doing so often results in gaps in the procedure. A good test for the level of detail for your procedure is to have some of your more junior staff execute the procedure. If they can do it cleanly, then there is likely sufficient detail to your procedure. If not, provide additional detail to your procedure. Also, make sure everyone who may execute the procedure has the proper access/permissions. The terms "policies and procedures" sound bureaucratic and, to many, is out of place in the dynamic world of information technology. IT departments are constantly tasked with adapting to new requirements, responding to changing business environments, and meeting aggressive project schedules. It is not uncommon to hear complaints about formal policies and procedures slowing things down—and sometimes they do, but that is not necessarily a bad thing. 25 Source: Linford & Co., as at https://linfordco.com/blog/security-procedures-building-on-the-foundation-ofsecurity-policy/, as on 9th May, 2017. 169 | P a g e Policies and procedures define standards and methods for accomplishing specific tasks. In contrast, ad hoc methods tend to "re-invent the wheel," depend upon undocumented practices, and often leave systems more difficult to maintain than they should be26. Policies are statements of objectives and direction that guide implementations. For example, an organization might have a policy that all sensitive data that leaves the internal network should be strongly encrypted. Procedures are step-by-step instructions for implementing a policy. In the example just mentioned, a procedure for encrypting sensitive information on mobile devices might include the installation of a program that automatically encrypts all data stored on the devices longterm storage mechanism. From an information asset protection perspective, several policies should be defined, including those that define: Acceptable use—Who is allowed to use the organization's information systems? For what purpose? Under what conditions? Access control standards—How are users authenticated to systems? What are password standards? How are users assigned to security roles? Who has authority to change access privileges? Anti-malware practices—What anti-malware software should be used? How frequently should full scans be performed? How frequently should devices check for updates? Who is responsible for responding if a malware attack is detected? Audit and vulnerability assessment procedures—What topics should be examined in an information security audit? How frequently should they be conducted? How should vulnerability assessments be performed? How should detected problems be remediated? Client device security—What security programs must run on client devices? What specialized restrictions apply to notebooks, PDAs, smart phones, and other mobile devices? What privileges are users granted to modify their local machines? Is the use of USB memory devices allowed? Email use and retention policies—What is the acceptable use of email systems? How should incoming and outgoing email be scanned? What are quarantine procedures for potentially malicious code or inappropriate content? Encryption use—When should encryption be used? What algorithms and key lengths should be used? How should keys be stored and distributed? Information privacy—What information is considered private, confidential, or sensitive? What are the rules for disclosing such information? In what situations should personally identifying information, such as Social Security numbers, be collected? What regulations and corporate governance policies apply to privacy protections in information systems? Risk analysis—How should information assets be valued? What are the organization's levels of risk tolerance? Server security—How should servers be locked down? What OS services should be allowed to execute? What restrictions are applied to servers that are accessible directly from the Internet, for example, those in a DMZ? Wireless security—Under what conditions are wireless access points deployed? Which wireless security protocols will be used? How will rogue devices be detected? 26 Source: Tech Target, as at http://searchsecurity.techtarget.com/feature/Developing-and-MaintainingPolicies, as on 9th May, 2017. 170 | P a g e It might be difficult o develop polices for all of these areas immediately. Start with the acceptable use policy, access control standards, anti-malware, and information privacy area. If wireless devices are used in your organization, develop a wireless security policy as soon as possible. As with any aspect of security, you must prioritize based on the needs of your organization. There are other areas that warrant formal policies—for example, when virtual private networks (VPNs) are used, when third parties are granted access to key applications, and when procuring IT assets. Policies serve a unifying purpose by describing what is to be accomplished; this is especially important when multipoint solutions are deployed. Company security policies are designed to create a safe workplace for employees and management. In 2009, there were approximately 572,000 instances of workplace crime such as assault and robbery committed in the United States, according to the U.S. Department of Justice website. Company management develops security policies, but employees have responsibilities toward those policies to maintain a safe and effective workplace27. Comprehension Management develops workplace security policies and training programs to familiarize employees with the ways to maintain a safe workplace. But management cannot force employees to understand all of the policies. It is the responsibility of employees to benefit from workplace security training and to come away with a comprehensive understanding of policies. If an employee does not understand a policy, or did not get information on a security measure, she must approach management to get clarification or more information. Vigilance Employees need to remain vigilant when it comes to executing security policies in the workplace. When an employee sees suspicious activity, he needs to follow security procedures and report it. A workplace security policy is effective only if it is used and practiced. Employees should make it a point to attend all security training classes and to be ready to use security procedures at all times. Personal Space Part of employee responsibility in maintaining a company security policy is being responsible for his own area. Employees need to make sure that their work areas adhere to security standards, and each employee must be certain that her personal effects in the work area do not hamper security. For example, if an employee has a large plant on top of his file cabinet that blocks a security camera, that plant needs to be moved. 27 Source: Chron, as at http://smallbusiness.chron.com/employees-responsibilities-maintain-security-policy12087.html, as on 9th May, 2017. 171 | P a g e Procedures Employees need to have respect for corporate security procedures to allow those procedures to be effective. For example, an employee should refuse to assist a co-worker in bypassing the cardswiping entry system because the co-worker forgot her access card. The employee should remind the co-worker of the security procedure in place for people who misplace their access cards. Application security has become a critical issue for large and midsize organizations. From high-profile data theft associated with Web applications to compliance requirements that impact applications of all shapes and sizes, securing your applications demands constant vigilance. Not only are the costs of security failures high, but so are the costs related to identifying defects and fixing vulnerabilities28. As the risks and consequences of security breaches continue to rise, comprehensive security protection can no longer be considered an afterthought, it must be built into every phase of your development life cycle. With so many security solutions available, enterprises like yours need to identify solutions that offer the most effective blend of capabilities and functionality to help reduce risks and overall costs. When evaluating application security and risk management solutions, however, you might find yourself confronted with vague product benefit statements and seemingly favorable pricing offers driven by vendors who want to steer purchasing decisions to their specific solutions. How can you increase your organization’s leverage and make an educated decision? By carefully evaluating vendors against the key capabilities listed below, which typically characterize best-in-class security and risk management solutions. Decision makers in your organization will be able to select solutions that reduce security risk while simultaneously lowering the cost of addressing vulnerabilities. Your ultimate goal should be an integrated, end-to-end life cycle approach to security and risk management. Your Vendor Selection Checklist Does the vendor your organization is considering provide: Comprehensive, advanced security testing and risk management technologies that permit you to identify areas of highest potential risk so that you can target those risks for future remediation? Broad coverage of current Web-based and mobile application security technologies? Comprehensive security program management capabilities, which can be applied to your entire application development life cycle? Testing support for the large and diverse volume of applications that are currently deployed by your organization or are slated for future deployment? Policies, reporting and work flow tools for security governance and risk management? 28 Source: Security Intelligence, as at https://securityintelligence.com/best-application-security-riskmanagement-solutions/, as on 9th May, 2017. 172 | P a g e A broad and diverse portfolio of security solutions that can be deployed in conjunction with security testing technology to improve your overall security protection and reduce overall risk? Once a set of solutions is evaluated against these criteria, you are bound to find a wide disparity between limited, one-size-fits-all security offerings and superior solutions that offer integrated, endto-end life cycle approaches to application security and risk management. Benefits of Early Application Security Testing In our “IBM X-Force Threat Intelligence Quarterly – Q1 2014” report, we documented 8,330 security vulnerability disclosures in 2013, an increase of more than 1,000 disclosures since 2011. Of those vulnerabilities, roughly a third of them were targeted at Web applications. In its “2013 Cost of Data Breach Study: United States,” the Ponemon Institute estimated that data breaches cost companies an average of $188 per compromised record in 2012; major data breaches could easily end up costing your organization hundreds of thousands — if not millions — of dollars. Countless security studies highlight the brutal fact that nearly every Web application contains vulnerabilities. If these vulnerabilities are not addressed proactively and result in a loss of customer data, your organization is likely to face costly lawsuits, damage to your brand image and an erosion of customer trust. Not only are the costs of responding to such security incidents high, but the costs of identifying and fixing application defects that result in data breaches are also expensive in the first place. To maintain software release schedules, many organizations conduct security testing after their software exits the system testing/quality assurance (Q/A) phase. In fact, many defects aren’t even identified until applications reach production phase. The cumulative financial impact of such latestage testing can be enormous. The National Institute of Standards and Technology (NIST) calculates that the cost of correcting a software error in the post-product release phase is approximately 30 times the cost of addressing the same issue during the coding phase of development. It’s clear that the risks and consequences of security breaches continue to rise and that comprehensive security protection can no longer be considered an afterthought. Rather, security protection must be built into every phase of your development life cycle and also into your Q/A process. Making Your Case for an Integrated, End-to-End Life Cycle Approach With a wide range of application security solutions available, organizations need to weigh the relative benefits of each potential solution while also evaluating potential costs. For most organizations, an integrated, end-to-end life cycle approach to securing applications produces the best outcome. However, many organizations still utilize a variety of point solutions to conduct security analysis, many of which are expensive to purchase and/or maintain and fail to provide comprehensive security testing. 173 | P a g e Often, point solutions offer primitive security governance processes that are limited in scope or require manual user intervention, limiting your ability to increase organizational efficiency and reduce costs. But the benefits of comprehensive security and risk management solutions are compelling. Mediumand large-sized organizations that leverage best-in-class application security and risk management tools are able to: Locate more vulnerabilities. By utilizing a comprehensive set of security testing tools that can be deployed at each stage of development, software development teams aren’t left guessing about testing coverage. Accelerate discovery and tracking of security vulnerabilities. The more comprehensive the deployment of security testing procedures, the earlier the procedures can be applied in your software development life cycle. Consequently, vulnerability detection is promoted to an earlier stage of your development life cycle. Reduce the cost of fixing security vulnerabilities. Moving remediation to an earlier point in the software development life cycle will save your organization time and money. As noted earlier, fixing a security issue in the coding stage results in much lower costs than eliminating it during the post-product release phase. Reduce the cost of implementing security governance and risk management best practices. Built-in work flow and tools to support large-scale application security testing, manage security issues that are identified, reduce security risk, track compliance and integrate security intelligence analysis into the development life cycle are all essential components of effective application security management programs. The solution you choose should reduce your expenses while increasing efficiency. Furthermore, when developers see clear links between risks and the code that results from those risks, they can focus on building secure applications rather than spending an inordinate amount of time determining where risks might exist in the code base. Activity 7 Who is responsible for Execution of enterprise and ICT system or application security policies on a typical organisation? 174 | P a g e Activity 7 175 | P a g e Activity 7 Create System-Level Security Architecture Key subtasks follow for the task, Create System-Level Security Architecture. Identify Technical Security Controls At this point, the task is to develop a list of the technical security controls that trace back to the prioritized security goals and requirements. These include technical control methods such as: • Network, and application access controls • Authentication requirements • Encryption • Redundancy • System hardening (configuration) procedures • Etc. Identify Non-Technical Security Controls Similarly, the task here is to identify a list of non-technical controls that trace back to the previously determined security goals and requirements. They include items such as: • Multiple-signatures • Separation of duties/functions • Etc. 176 | P a g e Other important tasks in the architecture and design phase follow. Perform Architecture Walkthrough At this stage, the key is to review the proposed technical & non-technical controls to ensure they accomplish the security goals. Create System-Level Security Design The design process will likely be an iterative process that will start with more basic lists and be enhanced to provide additional specificity. In the top-level design the tools, services, sub-systems, etc. that will provide the technical security controls are more fully detailed. This would include detailed security tools/service lists, top-level network diagrams, data flow diagrams, object lists, etc. On the nontechnical side specific processes/procedures are listed and top-level process integration diagrams are created in the CONOP (detailed below). The processes/procedures are detailed in subsequent steps. Top-Level Non-Technical Security Design – Concept of Operations (CONOP) A Security Concept of Operations (CONOP) is a high-level outline of security-related processes and procedures. Its common processes and procedures break down into the following categories: • Core Information Security Processes -- Address the most critical aspects of security, and are typically created, owned, maintained, and performed by the security organization, or a matrix team with security responsibility. Processes are usually of long duration (days, weeks, months) or ongoing in nature. • Core Information Security Procedures -- Typically created and refined by the security organization, or a matrix team with security responsibility. Procedures are typically of short duration (a few minutes or days). • Information Technology (IT) Processes -- Typically managed by various IT departments, but require some level of integration with security processes and procedures. • Business Processes -- Maintained outside of the IT department, and require integration with various Information Security processes or procedures. Apply and verify compliance with identified standards against which to engineer the ICT system or application A systems development life cycle is composed of a number of clearly defined and distinct work phases which are used by systems engineers and systems developers to plan for, design, build, test, and deliver information systems. 177 | P a g e Like anything that is manufactured on an assembly line, an SDLC aims to produce high-quality systems that meet or exceed customer expectations, based on customer requirements, by delivering systems which move through each clearly defined phase, within scheduled time frames and cost estimates. Computer systems are complex and often (especially with the recent rise of serviceoriented architecture) link multiple traditional systems potentially supplied by different software vendors. To manage this level of complexity, a number of SDLC models or methodologies have been created, such as "waterfall"; "spiral"; "Agile software development"; "rapid prototyping"; "incremental"; and "synchronize and stabilize"29. SDLC can be described along a spectrum of agile to iterative to sequential methodologies. Agile methodologies, such as XP and Scrum, focus on lightweight processes which allow for rapid changes (without necessarily following the pattern of SDLC approach) along the development cycle. Iterative methodologies, such as Rational Unified Process and dynamic systems development method, focus on limited project scope and expanding or improving products by multiple iterations. Sequential or big-design-up-front (BDUF) models, such as waterfall, focus on complete and correct planning to guide large projects and risks to successful and predictable results. Other models, such as anamorphic development, tend to focus on a form of development that is guided by project scope and adaptive iterations of feature development. In project management, a project can be defined both with a project life cycle (PLC) and an SDLC, during which slightly different activities occur. According to Taylor (2004), "the project life cycle encompasses all the activities of the project, while the systems development life cycle focuses on realizing the product requirements". SDLC is used during the development of an IT project, it describes the different stages involved in the project from the drawing board, through the completion of the project. The SDLC isn't a methodology per se, but rather a description of the phases in the life cycle of a software application. These phases (broadly speaking) are, investigation, analysis, design, build, test, implement, and maintenance and support. All software development methodologies (such as the more commonly known waterfall and scrum methodologies) follow the SDLC phases but the method of doing that varies vastly between methodologies. In the Scrum methodology, for example, one could say a single user story goes through the all the phases of the SDLC within a single 2 week sprint. Contrast this to the waterfall methodology, as another example, where every business requirement (recorded in the analysis phase of the SDLC in a document called the Business Requirements Specification) is translated into feature/functional descriptions (recorded in the design phase in a document called the Functional Specification) which are then all built in one go as a collection of solution features typically over a period of three to nine months, or more. These methodologies are obviously quite different approaches yet, they both contain the SDLC phases in which a requirement is born, then travels through the life cycle phases ending in the final phase of maintenance and support, after-which (typically) the whole life cycle starts again for a subsequent version of the software application. 29 Source: Wikipedia, as at https://en.wikipedia.org/wiki/Systems_development_life_cycle, as on 9th May, 2017. 178 | P a g e Phases The system development life cycle framework provides a sequence of activities for system designers and developers to follow. It consists of a set of steps or phases in which each phase of the SDLC uses the results of the previous one. The SDLC adheres to important phases that are essential for developers, such as planning, analysis, design, and implementation, and are explained in the section below. It includes evaluation of present system, information gathering, feasibility study and request approval. A number of SDLC models have been created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental, synchronize and stabilize. The oldest of these, and the best known, is the waterfall model: a sequence of stages in which the output of each stage becomes the input for the next. These stages can be characterized and divided up in different ways, including the following: Preliminary analysis: The objective of phase 1 is to conduct a preliminary analysis, propose alternative solutions, describe costs and benefits and submit a preliminary plan with recommendations. 1. Conduct the preliminary analysis: in this step, you need to find out the organization's objectives and the nature and scope of the problem under study. Even if a problem refers only to a small segment of the organization itself, you need to find out what the objectives of the organization itself are. Then you need to see how the problem being studied fits in with them. 2. Propose alternative solutions: In digging into the organization's objectives and specific problems, you may have already covered some solutions. Alternate proposals may come from interviewing employees, clients, suppliers, and/or consultants. You can also study what competitors are doing. With this data, you will have three choices: leave the system as is, improve it, or develop a new system. 3. Describe the costs and benefits. Systems analysis, requirements definition: Defines project goals into defined functions and operation of the intended application. It is the process of gathering and interpreting facts, diagnosing problems and recommending improvements to the system. Analyzes end-user information needs and also removes any inconsistencies and incompleteness in these requirements. A series of steps followed by the developer are: 1. Collection of Facts: End user requirements are obtained through documentation, client interviews, observation and questionnaires, 2. Scrutiny of the existing system: Identify pros and cons of the current system inplace, so as to carry forward the pros and avoid the cons in the new system. 3. Analyzing the proposed system: Solutions to the shortcomings in step two are found and any specific user proposals are used to prepare the specifications. Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation. 179 | P a g e Development: The real code is written here. Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability. Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business. Maintenance: During the maintenance stage of the SDLC, the system is assessed to ensure it does not become obsolete. This is also where changes are made to initial software. It involves continuous evaluation of the system in terms of its performance. Evaluation: Some companies do not view this as an official stage of the SDLC, while others consider it to be an extension of the maintenance stage, and may be referred to in some circles as post-implementation review. This is where the system that was developed, as well as the entire process, is evaluated. Some of the questions that need to be answered include: does the newly implemented system meet the initial business requirements and objectives? Is the system reliable and fault-tolerant? Does the system function according to the approved functional requirements? In addition to evaluating the software that was released, it is important to assess the effectiveness of the development process. If there are any aspects of the entire process, or certain stages, that management is not satisfied with, this is the time to improve. Evaluation and assessment is a difficult issue. However, the company must reflect on the process and address weaknesses. Disposal: In this phase, plans are developed for discarding system information, hardware and software in making the transition to a new system. The purpose here is to properly move, archive, discard or destroy information, hardware and software that is being replaced, in a manner that prevents any possibility of unauthorized disclosure of sensitive data. The disposal activities ensure proper migration to a new system. Particular emphasis is given to proper preservation and archival of data processed by the previous system. All of this should be done in accordance with the organization's security requirements. In the following example (see picture) these stages of the systems development life cycle are divided in ten steps from definition to creation and modification of IT work products: 180 | P a g e The tenth phase occurs when the system is disposed of and the task performed is either eliminated or transferred to other systems. Not every project will require that the phases be sequentially executed. However, the phases are interdependent. Depending upon the size and complexity of the project, phases may be combined or may overlap. Activity 8 Describe the actions that could be taken if it is determined that the ICT system does not meet required compliance standards. 181 | P a g e Activity 8 182 | P a g e Activity 8 183 | P a g e Activity 8 Perform processes and procedures to mitigate the introduction of vulnerabilities during the engineering process Implementation Phase – – Inspection and Acceptance – ensures that the organization validates and verifies that the functionality described in the specification is included in the deliverables. – Security Control Integration – ensures that security controls are integrated at the operational site where the information system is to be deployed for operation. Security control settings and switches are enabled in accordance with vendor instructions and available security implementation guidance. – Security Certification – ensures that the controls are effectively implemented through established verification techniques and procedures and gives organization officials confidence that the appropriate safeguards and countermeasures are in place to protect the organization’s information system. Security certification also uncovers and describes the known vulnerabilities in the information system. – Security Accreditation – provides the necessary security authorization of an information system to process, store, or transmit information that is required. This authorization is granted by a senior organization official and is based on the verified effectiveness of security controls to some agreed upon level of assurance and an identified residual risk to agency assets or operations. 184 | P a g e Why is Security Testing in the SDLC important?30 Security testing is one of the most important aspects of any Secure SDLC approach. Why? For one, security testing in the SDLC identifies security issues that need to be addressed. The sooner you can find them, the more money you save: fixing security issues, like any bugs, gets more expensive the later in the lifecycle you find them. Waiting until later stages of the SDLC to begin security testing leads to hasty fixes in order to stay on schedule will not bode well when customers complain – or worse. And that’s not even considering the kinds of costs we’ve seen organizations pay when they don’t discover a vulnerability at all. Breaches are costly, and the ROI gained from proper implementation of security testing in the SDLC is proven by avoiding just one security breach. Secondly, the various types of tests you’ll perform throughout the lifecycle will also let you know how closely the security architecture and design is being followed. In essence, security testing is a barometer of security quality within your SDLC, as well as the best way to develop and maintain applications efficiently and in line with organizational needs and risks. 30 Source: Checkmarx, as at https://www.checkmarx.com/2016/02/26/security-testing-sdlc-beginners-guide/, as on 10th May, 2017. 185 | P a g e Lastly, but perhaps most importantly, security testing gives an organization a strategic approach to improving security in their application portfolio, and is a business imperative for any business trying to minimize the potential risks – including compliance requirements – that application security vulnerabilities can pose. Where Does Security Testing Fit in the SDLC? Security testing can be done through much of the SDLC, as early as during the analysis and design phases, as well as throughout development and, of course, during the testing phase. And just because an application is released, doesn’t mean you can stop thinking about the application – but we’re focusing on testing done during the lifecycle for now. The security testing strategy, as we discuss below, needs to be based on your individual organizational structure and what the established SDLC process allows for. Typically, however, security testing can be broken up into three areas during the SDLC: Requirements and Analysis Phase During this phase, as security requirements are mapped out, testing plans can be created to better track the completion and success of the stated requirements. Development Phase 186 | P a g e As soon as code is being written, static application security testing can begin. Starting testing as soon as your SDLC allows facilitates the best way to stop vulnerabilities from making their way to the finished product. With partial code scanning, source code can be scanned at any point in time during the build, making vulnerability discovery that much faster and more effective. Code Reviews & Manual Testing Phase Finally, once development is finished, a final secure code review along with manual testing can help detect logical code flaws and ensure that issues found during the development phase have been fixed correctly and new vulnerabilities have not been introduced. Defence in depth is a key aspect to a successful application security program – and the same goes for security testing in the SDLC. 4 Key Steps to Security Testing in the SDLC: 1. Make it measurable As the OWASP Testing Guide so rightly says in the introduction, “you can’t control what you can’t measure.” Security testing is no different – especially when first implementing it within the SDLC. Being able to look through your testing history and comparing it over time is essential in seeing (and reporting up) on improvement. In order to do so, begin by establishing goals and metrics from the get-go, working with stakeholders – from the board to developers – to set expectations and gather feedback on the processes themselves. 2. Ensure testing tools are easy to adopt Making sure the tools you choose are chosen in terms of learning curve and adoption rate by developers are important factors in whether or not your security testing program will be successful or not. Many developers haven’t dealt with needing to test for security before, so if a tool is difficult to use or well-integrated into the developer’s current toolset, chances are it’s not going to get used. Don’t spend a fortune on the “best tool in the business” if it’s not likely to be used by those that would be in the business of using it. 3. Automate wherever possible If you’re doing a good job of training your developers, you want to make sure they’re spending the most time doing what they were hired and trained to do – code securely. Instead of burdening them with long hours of code review or manual security testing at each milestone, you can automate at least parts of that process with source code analysis tools, implemented into their IDE. At check-in, developers can simply scan their code and get quick results back instantly, allowing them to fix the code while it’s still fresh in their minds. 4. Align security testing activities to your current SDLC process 187 | P a g e The phases you’ll be able to integrate security testing into and how quickly security testing can be introduced largely depends on the existing SDLC process in place in your organization. In agile environments, for instance, security testing can and should be integrated as early as possible, while in waterfall environments, security testing may not be possible until development is well-underway. While security testing should always be integrated as early as possible, it’s more important to make sure security is a business enabler by working with the current processes – not against them. Perform secure configuration management practices Operations / Maintenance Phase – – Configuration Management and Control – ensures adequate consideration of the potential security impacts due to specific changes to an information system or its surrounding environment. Configuration management and configuration control procedures are critical to establishing an initial baseline of hardware, software, and firmware components for the information system and subsequently controlling and maintaining an accurate inventory of any changes to the system. – Continuous Monitoring – ensures that controls continue to be effective in their application through periodic testing and evaluation. Security control monitoring (i.e., verifying the continued effectiveness of those controls over time) and reporting the security status of the information system to appropriate agency officials is an essential activity of a comprehensive information security program. When you think of configuration management, what is the first thing that springs in your head? Usually when I ask people this question, I generally receive an answer along the lines of software development, or some type of engineering deliverable31. Traditionally, configuration management has its roots in the manufacturing and software development arenas; something that is an actual deliverable. Configuration management follows a linear path, similar to project management, and revolves around the control and release of different product versions. Until recently, security was not on the radar of configuration management professionals with the exception of the physical security. However, for the past few years configuration (sometimes also referred as Change Management) has been finally gaining ground as a discipline that is in demand in the security world. Right now it is in its infant stages as vendors, and security professionals attempt to categorize or better define the role of configuration management in the security discipline. Depending on who you talk to configuration management can mean different things, it can mean how your network devices are configured, or it can mean what version of the application you are running, it could mean what was the last patch installed on your device., or the baselines hardware and applications that run on your devices. Ask yourself, what does configuration management mean to you? Does it strictly revolve around 31 Source: SANS, as at https://www.sans.edu/cyber-research/security-laboratory/article/meyer-configmanage, as on 10th May, 2017. 188 | P a g e CMM, or CMII? Does it involve an administrative only process such as a CCB? Now ask yourself who is the configuration management professional in your organization? Now ask yourself is this person also a security professional? If not they should be, and if you don’t have yourself a configuration management professional you better get one into your security department, and here’s why. Configuration management drives information security and information assurance. It’s in everything and is imbedded everywhere, but few people acknowledge this fact, and your organization may be suffering because of it. It’s how you manage your infrastructure, its how you manage your information security program, its how you build and manage your information security process. Every security professional should have some type of configuration management skills in their tool box, along with everything else. It’s pointless to buy the best firewall on the market, and not have a good SOP to maintain its configuration so only authorized traffic crosses it. You should think of configuration management kind of like the tumbler within the lock on the front door of your home. You could buy a steel door, and put a tank of a lock on it to keep everyone out, but if you don’t configure the tumblers within the lock, anyone can get in and all of that time and effort is wasted. Lack of configuration management puts additional risk to your environment. The diagram below shows the many areas that configuration management resides within your security program. As a rule of thumb, configuration management can be broken down into three distinctive disciplines for your environment, with all three of them having different requirements, process and tools. The three disciplines are: 1. Business Process Infrastructure (Chain of Command, CCB) 2. Operations and Services (Operational Group) 3. End Products (technical group) The Business Process Infrastructure weather you are federal government or commercial sector is the backbone for the rest of the organization. The business process is where the rules and responsibilities are identified, policy is written and accepted, and more importantly it is where the process is built in order to successfully manage the security posture of your organization. Your business process infrastructure is where your authority originates, and the correct people are given the correct level of authority and executive buy in order to make change with the organization as the security threat changes. Your business process infrastructure needs to be built with the mindset of accommodating change. Unfortunately, many organizations do not allow for enough flexibility in their change process that allows for rapid reconfiguration requirements, which are necessary in the security environment. Many configuration management professionals either put too little effort into accommodating change, or put too much effort in locking down the change with excess efforts making change difficult. Examples of these deficiencies in proper business process infrastructure were the past Veterans Department data loss. Many security best practices where not enacted due to the executive leadership not giving the proper personnel the correct level of authority necessary in order to enact change. Additionally, the Navy set its business process infrastructure into a bottleneck in order to attempt to get a handle on their information Assurance efforts. Accommodating changes was not taken into consideration as a single point of failure was created which significantly reduce process flow. 189 | P a g e Configuration management plays a role in these efforts because the Configuration Management professionals should be the facilitators of this process. They are not the process owners, rather than the process facilitators. Configuration management owns the document creation, revisions, releases, and process improvement activities for the business process infrastructure, and influences best practices. A configuration management professional should be knowledgeable enough in security and information assurance in order to begin process improvement utilizing security best practices in the dosing of organization business process. Once the security business process infrastructure framework is designed, documented, accepted and put under configuration control, the next area of concern is the configuration, and change controls of enterprise services and operations. This is completed by developing and taking configuration requirements operational. This also is a critical step in the building of the secure infrastructure, and is the meat and potatoes of providing a defense in depth to your organization. The authority is driven by the acceptance of the business process infrastructure, however, the operational needs, wants, and the protection profiles requirements to meet the need, and want requirements are developed within this operation framework. Configuration management again is the process facilitator, the CM professional needs to ensure their process flows take all operational services provided by the organization, can accommodate change within it from cradle to grave. A possible framework is displayed in the following figure. This is a typical operational framework under configuration control for active management. The CM professional generally does not fill the role of making the sole decisions of the baseline configuration requirements for each domain within the framework, but is an active team member in the creation of the baseline standards. The CM role should be the primary facilitator of change to baseline framework, and ensure that the As-Built infrastructure is current in real time. The CM professional should be able to manage three different levels of enterprise architecture utilizing security best practices, the As-Built, the To-Be, and the As-Planned. 190 | P a g e Each area of focus has distinct security affects for the enterprise. The As-built is the real time operation of the enclave in real time directly supporting the mission of the organization. This is where the change management process controls what is built into the infrastructure, what data transverses the infrastructure and what is decommissioned from the infrastructure. The To-Be environment is the next generation of the infrastructure that is needed to support the every fluid environment of today’s rapid reconfiguration requirements. The To-Be environment represents the near future architecture and protection profiles needed to sustain operations. This is where configuration management plays a large role within the enterprise architecture discipline. The CM professional should know everything about an organizations As-Built so that decision makers are armed with the correct data to make educated decisions about their architecture. Generally the ToBe is at a stage where actual hardware and software needs have been identified in detail, integration testing has been completed. The To-Be environment is where Information Systems Security Engineering (ISSE) process is at their best. The As-Planned environment is the long term view of the organizations enclave. The As-Planned is generally high level architecture for propos3ed future needs wants. All needs start in the As-Planned stage of the life cycle, where they are more finally tuned to meet stricter and more defined requirements as they progress from the As-Planned to the To-Be, and finally into the As-Built. This is all facilitated by configuration management. The COOP area of the framework again is not the sole property of configuration management but again they are a critical team member in the development of it. The CM professional should be able to assist any security professional with critical data required in order to effectively build the COOP elements. Configuration Management should know where assets are, what they are, what they are doing, and who they were doing it with. This gives security personnel which solid data to better assess backup strategies, critical devices, disaster recover prioritization, and business impact analysis. Generally document library control falls under the configuration management group for quality assurance, for which ISO 900 series is popular. As device, data flow, and capabilities are added and decommissioned from each environment, the COOP documentation needs to be consistently revised and released in order to capture the impact of the change. Typical security practices are overlooked, since accommodating change is not front loaded into the environment, changes to the environment are not captured in the latest revision of the COOP, this in turn can be catastrophic in the event of an incident. The CONOPS is where the operation configurations requirements and processes reside. For the DOD the DIACAP Knowledge Service is a good example of where a CONOPS policy and process can be drafted from. The DIACAP Knowledge service controls are under DIACAP TAG configuration control. As threats change, the controls can be changed to assist in mitigating the threat. Configuration Management should maintain this operations document to reflect the current controls posture, setting the baseline for user operations. The CONOPS should outlines policy, and process required in order to fulfill the daily duties of the organization such as the firewall change process, Access controls levels, user roles, and responsibilities. The CONOPS is a living document that changes as the current threat changes in regards to normal operations. The CONOPS is an operational baseline and should also fall under configuration control. 191 | P a g e The Audit domain in the framework is the checks and balances, as well as compliance area for the environment. Regular audits should always be included into all process with the organization in order to help maintain internal compliance. Audits not only provide a valuable metric in assessing your security posture overall, but it also provides a number of security improvement. Organizational Compliance - Compliance does not result in good security, but good security does result in compliance, therefore, weather you are looking for FISMA or SOX type compliance you should be well on your way because you are a security practitioner, by being proactive, and not reactive. Continuous Improvement - Audits allow the decision makers the ability to quantify if processes are effective, this allow decision makers the ability to intervene as integrity declines. The audit domain is the obvious; it is a method of checks and balances to maintain the appropriate security posture. End product configuration management is the management of the As-Built devices themselves, and is generally where the current commercial tools venders are focusing on. This area of focus is also the most technical of all of the areas, and if developed properly in conjunction with the other configuration management areas is the most important. The end product configurations should be designed in the To-Be domain for operation deployment. When a new need and want is identified in the As-Planned architecture, then further analysis selects and actual product to perform that want, the baseline configuration for that device should be assembled. The CM professional should be the facilitator of this baseline, to maintain the security posture of the environment, by utilizing the System development life cycle, in addition to the information systems security engineering processes. This is where the CM professional Information Security engineer, and systems engineer should converge and team, to establish as baseline, that: 1. Meets system requirements 2. Meets security requirements 3. Can be moved into the As-Built and integrate Many times, these efforts are undertaken in different phases of system development, when in actuality they must be undertaken in a teaming environment. This is the reason why a Project Engineering Review Meeting (PERM) should be utilized. The purpose of the PERM is to take an AsPlanned requirement, and build a To-Be solution, for future transition into the AS-Built after approval from the CCB. The PERM is the critical exchange of communications, and talent that is generally missing from many organizations. Lack of a PERM type capability, is generally the sole reason why project fail, to either meet requirements, meet security needs, which in turn results in delays and cost overruns, in additional to putting additional risk to the infrastructure. Configuration management is a growing discipline and can provide a solid backbone in order to maintain secure operations. The role is growing, and continuous to influence the IT realm as more and more capabilities with IT infrastructure. In order to practice true defense in depth, an identified and accepted configuration management role needs to be introduced into the security operations. 192 | P a g e Defence in Depth can now be viewed in three dimensional terms. As security services, such as Cryptography, Firewalls, Intrusion detection and prevention are deployed, in addition to the CM framework, and building these solution based on the differing levels of IT will provide a robust security, operations, and compliance best practice. Deployment/Implementation This phase involves taking an application from the testing environment to the production environment for limited (e.g., pilot) or full-production uses. Simply put, you want to make sure the people carrying out the deployment follow the security related processes and procedures that you set up in the preceding phases. Deploy Training and Awareness Program This task entails implementation of a security training and awareness program. Administrative personnel and users should be schooled in the system's security functions. Secure Configuration Management32 When considering secure configuration management, the biggest challenge may be simple nomenclature— everyone calls this something different. SANS calls these controls “secure configurations” for servers, workstations, and network and security devices. The National Security Agency (NSA) calls the same thing “patch management” and “baseline management,” among other things. 32 Source: SANS, as at https://www.sans.org/reading-room/whitepapers/analyst/secure-configurationmanagement-demystified-35205, as on 10th May, 2017. 193 | P a g e The Payment Card Industry Data Security Standards (PCI DSS) compliance standard refers to requirements for secure configurations such as “Do not use vendor-supplied defaults for system passwords and other security parameters” and “Develop and maintain secure systems and applications,” without explicitly using the terms “configuration management” or “secure configuration.” In NIST 800-53 version 4, currently available as a draft for review, there is a general category of security controls labelled “configuration management.” Fundamentally, all of these terms refer to the same concepts and topics. Throughout this document we call this process secure configuration management. What exactly is secure configuration management? In a nutshell, secure configuration management is the technical application and maintenance of security policy on systems, applications and network devices. There are several distinct disciplines that exist within the realm of secure configuration management, including the following: Configuration Management Planning and Management This aspect of configuration management is primarily concerned with developing the configuration management plan, including who will manage it, what type of Configuration Management Database (CMDB) will exist, and what types of tools and processes will be employed. Configuration Identification During the Configuration Identification stage, specific Configuration Items (CIs) are defined for individual platforms. These are what will be implemented, measured and maintained over time. For systems and network devices, these controls may be driven by compliance mandates such as the PCI DSS and the Federal Information Security Management Act (FISMA), as well as National Institute of Standards and Technology (NIST) documents (e.g., 800-53) and the Center for Internet Security (CIS) and Defense Information Systems Agency (DISA) guides. Configuration Control CIs are implemented, organizations can deploy a monitoring system for the controls that focuses primarily on change detection and serves as an holistic change management program. This stage is implemented at two levels. The first application is within the overall CI database and the specific CIs for systems. When a configuration template needs to be changed or updated, it should be accommodated within the change management framework. The second way this phase is managed is at a local level, where changes need to be monitored, implemented, and in some cases, rolled back or remediated when the change is either unplanned or due to malicious activity. Configuration Status Accounting This configuration management process focuses on defining and documenting baseline configurations and then maintaining the baselines over time. Configuration Verification and Audit 194 | P a g e Configurations for systems and network devices need to be audited and monitored, with detailed reports prepared for comparison with existing and planned baselines. Performing such audits continuously is best for maintaining adequate security, but regularly scheduled routine audits can also be implemented. Configuration Remediation After configuration assessments are performed, there will usually be a variety of configuration items that need to be corrected or changed in some way to meet policy and compliance specifications. IT operations teams usually perform these changes with input from audit and IT security groups. Remediation can be issued in the form of written guidance, as well as through more automated scripts and workflows that are kicked off after change approval. Challenges with Secure Configuration Management In an InformationWeek survey of CISOs, “enforcing security policies” was ranked as the No. 2 “biggest security challenge,” and the biggest overall challenge was managing complexity.13 of security and compliance-related controls maintained by security and operations teams into the following categories: Physical Host Operating Systems Physical servers and workstations make up the bulk of IT infrastructure. The operating platform that runs on these physical systems has a number of distinct controls including access controls, operating system tuning parameters and file-level controls for data storage. Virtual Operating Platforms and Guest Operating Systems As more organizations realize the cost savings and operational benefits of virtualizing systems, an increasing amount of virtual technology will be deployed. In addition to traditional operating system controls, these systems contain their own platform-specific code and virtual network infrastructure that require controls to be applied. To that end, virtualization brings about an entirely new layer of complexity, with a staggering array of new configuration items that should be evaluated and locked down. Applications and Databases Applications and databases have their own specific sets of controls to maintain and monitor. Web servers have access controls, file and directory permissions, as well as customized database calls and scripts, and databases have controls for data presentation and retention, as well as stored procedures and other database implementation-specific aspects. Network devices and Infrastructure 195 | P a g e Network devices such as routers, switches and firewalls all have specific controls that apply to segmentation of network traffic, inspection of traffic and encryption of traffic. For each of these four categories of infrastructure elements, there are significant numbers of configuration controls that can be applied to implement a specific security or compliance goal. All organizations will have basic physical security controls around hosts, but financial services organizations might have many additional layers of network security controls compared to a small software firm. The software firm, however, might have many more complex code repositories, databases and application-specific controls for some systems. In the case of virtualization, other layers of configuration controls are called for, such as locking down virtual machine files and securing the hypervisor. The sum of these controls constitutes a security or compliance posture that operates within the framework of internal policies and external regulations and mandates. While that sounds simple enough, managing these controls and processes has been difficult for organizations to follow holistically. For example, they may be managing their virtual hosts, but upgrades to the host platform may affect the virtual guest systems that run on it, leading to modifications in operating system parameters. Over time, the virtual hosts slip out of compliance with the CIS Windows 2008 Server benchmark that serves as their corporate configuration standard—most likely without the organization’s knowledge. Because this standard is what the auditing program has been built on, such change could lead to a failed audit or compliance violation as well as risky exposure. Whether in an IT environment that is managed internally, virtually or in the cloud, the primary culprit behind changes that “get out of hand” is, for most organization, a lack of visibility. This lack of visibility can be seen in a number of forms, including the following: Network Visibility Different subnets are segregated in such a way that certain systems cannot be identified from other parts of the network, or configurations are only visible to network operations teams. Application Visibility Ports and services may be unavailable to certain networks, groups or individuals. Configuration Visibility Certain groups and individuals may not have the access rights to determine a system or application’s configuration options. Communication Issues Certain groups may intentionally or accidentally withhold information from other teams, which leads to a lack of visibility. 196 | P a g e Without the proper visibility, many teams will not be up-to-date on what systems are deployed, what state those systems are in, and how these changes and discrepancies may affect other parts of the organization. This lack of communication presents the window of opportunity attackers look for to exploit. Aside from lack of visibility, many organizations have a tendency to leave the definition, management and governance of configuration management to individual groups or silos within IT. Rather than defining a central configuration management team that coordinates tools, processes and policies related to configuration management, many organizations let individual teams of administrators and engineers choose how and when to update and manage system configuration details. Organizations need a coordinated configuration management database or a well-maintained catalog of CIs that all teams refer to for baselines and updates. In most cases, not having such a resource is attributed to staff members not having enough time or senior management lacking commitment. Many IT professionals also feel there is not enough operational capacity to implement and manage a configuration management solution. These silos also lead to gaps in coverage of critical systems that open the doors to exploitation. There are also challenges with the technical aspects of configuration management. Tools that can both implement and manage configuration details for most platforms tend to come in agent-based formats, with some offering non-agentbased assessment mechanisms as well. Most organizations prefer not to install yet another agent on their systems if possible, due to the perception of reduced performance, more overhead, and possible compatibility issues with other existing software and operating system components. On the other hand, the agentless options tend to be implemented as remote scanning tools, which may have limited ability to implement configuration changes even when run with administrative credentials. The Department of Homeland Security explains in much more detail the pros and cons of using agents and agentless assessment in its Continuous Asset Evaluation, Situational Awareness, and Risk Scoring Reference Architecture Report (CAESARS). From the security perspective, any of these tools should be highly aware of changes to systems, as these are almost always the leading indicators of, or precursors to, security issues such as illicit logins, exploited vulnerabilities and malware installation. Ultimately, however, the only true way to monitor changes to server systems on a continuous basis, as recommended by the SANS 20 Critical Security Controls and other best practices, is by installing an agent. Yet, network configuration management tools lend themselves more readily to remote scanning-based assessments, because many of those operating platforms do not support agents in the first place. For this reason, it’s highly likely that a combination of both agented and agentless assessments will be required. In fact, SANS Critical Control 3 reinforces this point in its current language regarding metrics: “Any of these changes to a computer system must be detected within 24 hours and notification performed by alerting or sending e-mail notification to a list of enterprise administrative personnel. Systems must block installation, prevent execution, or quarantine unauthorized software within one additional hour, alerting or sending e-mail when this action has occurred. Every 24 hours after that point, the system must alert or send e-mail about the status of the system until it has been removed from the network or remediated. 197 | P a g e While the 24-hour and one-hour timeframes represent the current metric to help organizations improve their state of security, in the future organizations should strive for even more rapid alerting and isolation, with notification about unauthorized changes sent within two minutes.”15 Along those lines is another challenge related to the general timeliness of getting CI information and assessments. A monthly “megascan” is not only invasive, but it is also not sufficiently timely for critical CIs. A newly created illegal service or unexpected telnet session might be recorded by log or SIEM systems, but if not acted upon quickly, it could cause significant damage. Instead, if the security configuration process is real-time and self-reliant (and sometimes self-correcting), it actively serves as a last line of defence. Activity 9 What is meant by Configuration Status Accounting and what is its role in Security Configuration Management? 198 | P a g e Activity 9 199 | P a g e Activity 9 Management Once configurations have been applied, systems have a tendency to “shift and drift” from their original postures, which can lead to woefully insecure configurations that are susceptible to attacks. Therefore, ongoing management of the secure configuration tools and CIs is critical. There are several other aspects to proper management of security configuration: 200 | P a g e Exceptions The exception process for secure configuration application needs to be tied closely to change management. When exceptions are required to existing and planned configuration baselines, there should be extensive documentation of why the exception is needed, along with an approval workflow. Waivers Waivers should only be issued after the exception process has been successfully followed and documented. In addition, waivers should be revisited regularly to revisit mitigation options. Risk Management Regularly evaluating the risks of your current configuration templates and CIs should be a part of the secure configuration management lifecycle. Lifecycle Developing and applying a configuration to servers, workstations and network devices requires a cyclical approach that ensures configuration controls are updated, patches are applied and systems are evaluated regularly. Secure configuration management may allow security and operations teams to truly measure configuration baselines and then chart improvements over time, providing a rich source of meaningful metrics. For example, systems may be 50 percent compliant with a chosen configuration standard at the time of initial assessment, and remediation changes can modify this posture to 70 percent over a period of time dictated by project, change cycles and assigned priorities. Given the prevalence of breaches directly related to or involving configuration failures for systems and network devices, it’s important that organizations get back to basics and look at the fundamentals of securing systems and network devices. Implementing a secure configuration management program is essential to properly securing systems and data—and meeting compliance mandates. Unfortunately, many organizations, especially with the advent of virtualization and private cloud technology, are unable to keep pace with the growing complexity in their environments. The situation only gets worse without rigorous configuration audits and controls. A continuous audit of configuration state and new systems coming online is the best way to manage and monitor all the different infrastructure components that comprise today’s complex environments. Whatever management structure is put in place, organizations must consider changes and updates to their environments. Structured change management processes that do exist must consider that planned and unplanned changes occur out-of-band. Such changes ultimately lead to the majority of most security breaches. 201 | P a g e In out-of-band or unmanaged systems, patches aren’t applied, configurations are modified, and new virtual systems are brought online without any stewardship from risk managers. Using automation and policy to continuously monitor for changes and auditing configurations are the key means for mitigating risk in the first place, according to the SANS 20 controls and other authority documents. Secure configuration management can also help organizations know when something is occurring on their networks that shouldn’t be. Ultimately, proper secure configuration management should lead to continuous overall improvement in risk posture through reduced vulnerability and misconfiguration metrics and cleaner networked systems. Validate that the engineered ICT system and application security controls meet the specified requirements Develop Technical Configuration Standards and Procedures Especially in the case of large system rollouts, it is likely that the different teams will roll out the application and the underlying infrastructure. You should document how to perform these rollout activities securely, in a set of publications that outline: 1) technical security standards; and 2) technical configuration procedures. Technical security standards provide detailed rules that define what should be done at a technology level to mitigate security risks. The standards are related to network or systems infrastructure, for example, a router, operating system, network switch, or server. Other technical standards are related to the business applications being rolled out. Technical configuration procedures provide step-by-step instructions on how to configure an operating system or service, or a security software tool, such that it adheres to the rules detailed in the technical standard. For example, there may be step-by-step configuration instructions on how to securely configure a Windows NT server, or the newly developed application, to comply with security standards. Such publications help ensure that personnel are properly hardening the system by removing known vulnerabilities such as default passwords or unneeded services. Test Security The test phase verifies that all of the security-related components of the system work as advertised, and meet the expectations of owners and end users. In most cases, the security aspects of testing are integrated with the regular test plan. The exception is vulnerability testing. The first two tasks are typical test functions, with a security twist. The third task -- vulnerability assessment -- is a recently developed test function that is specific to security. 202 | P a g e Conduct Performance/Load Test With Security Features Turned On This task involves verifying that the system performs up to specification and meets production load requirements with the security components and features that are engaged. This task is often overlooked. Do not make the elementary mistake of forgetting to turn on all of the security features, discussed above, that apply to your system. Perform Usability Testing of Applications That Have Security Controls You should verify that security-related functions are ergonomically sound. If personnel are not accomplishing their work through the applications, for example, because the applications are overly time-consuming or difficult to use, you have to take remedial steps like training the employees or reengineering the system. Perform Independent Vulnerability Assessment of System (Infrastructure and Applications) You must verify that the infrastructure and applications cannot be compromised, and that attackers cannot use the applications to carry out unintended functions. Verification is essential prior to an application being implemented on your system or shipped to a customer, before a security flaw can do any damage. Vulnerability assessment has traditionally examined the infrastructure through such "ethical hacking" means as penetration testing. Still, you must not neglect assessing applications as well, especially in an Internet environment, where a skillful cracker can manipulate Web applications into performing unintended functions that compromise data. Crackers put large amounts of data into fields intended for only a few bytes. This technique, called a buffer overflow attack, can enable an attacker to directly control a system, or take control later by providing commands as part of the input string. One of the methods of accomplishing partial application-level vulnerability testing is to have the functional testing team add a set of negative test cases. Negative test cases refer to checking various functions, input fields, etc. for the result of unintended inputs. This is the opposite of positive test cases where the functional testing team is expecting certain results based on various application inputs. As outlined above, hackers will often try things that the application would not expect – e.g., buffer overflow situations. This verification is best performed by an independent organization. This would be an internal auditing group not associated with the application development effort, or an outside firm. The development teams have typically worked too closely with the products to objectively assess their security vulnerabilities. Independent, third-party verification can help to protect your organization against the threat of legal liability in the event of security incidents. Vulnerability assessments indicate, in legal parlance, that your organization is exhibiting "due care" to protect its own assets and that of clients. 203 | P a g e The courts recognize that there is no such thing as "perfect security." However, through the doctrine of due care, they do place the burden of taking prudent measures to protect assets upon the organization responsible for creating and maintaining the infrastructure and applications. Re-engineer security controls to mitigate vulnerabilities identified during the operations phase Perform Design Review Design reviews tend to be an iterative process. After conducting a high-level review, you work down to a detailed design review in order to fashion a final design. The high-level review should include an examination of requirements and current architectures, design solutions, a review of vulnerabilities, and an assessment of whether and how vulnerabilities can be eliminated. The detailed review should include a formal walkthrough. A key security-related area to check is the performance requirements and sizing of the system infrastructure (networks, servers, etc.), since security services will often overload services. It is important to go through a set of design reviews focused on the security aspects of the system. Depending on the design area being reviewed, business, application development, and security personnel should take part in these reviews. The series of design reviews should include the following: • Technical review geared to the application level • Technical review geared to the infrastructure level • Non-technical review (processes and procedures) Ensure integration of information security practices throughout the SDLC process Educate Development Teams on How to Create a Secure System The two main aspects of this task are: • Provide best practices for secure coding. • Provide practical education on using the various security tools and services. 204 | P a g e Application teams are, naturally, usually well-schooled in the art of development. However, they frequently do not understand the security aspects of development. The application teams require education and training in such matters as secure coding practices. They need to learn how to identify common vulnerabilities, and how to establish secure development environments. In addition, developers should be exposed, like the rest of the organization, to the general security principles. Another aspect of this task relates to training developers in specific security tools and services. In newer systems, developers make frequent use of external security services by means of application program interface (API) calls. In the "good old days" of mainframe "legacy system coding", many security-related functions like authentication and auditing were done within the application. In modern Web environments, by contrast, many security functions like access control are done via middleware services. In such settings, the developers can use within the operating environment a set of third-party tools, such as PKI, or services layered into operating systems, such as logging, auditing, authentication, etc. to accomplish security functions. Design End-User Training Awareness Measures The design of a training and awareness program is vitally important. All the security processes and hardware in the world will do little good if your personnel does not know how to use them. This is often missed or overlooked in training manuals and courses. In Web applications, especially with external users, security training and awareness often must be built into the application, or incorporated in "getting started" type of user education tools. Document ICT system or application security controls addressed within the system Assess and Document How to Mitigate Key Application and Infrastructure Vulnerabilities This task is a variation of bug tracking, in which you highlight security-related deficiencies. You have several options for handling these flaws. You can remove or mitigate them by tuning the design or reconfiguring the infrastructure. Alternately, if you are unable to eliminate or lessen vulnerabilities, you can deter them, or at least monitor for their occurrence. A parking lot owner wishing to reduce car thefts, for example, might deter thieves with extra street lighting, and monitor suspicious activity with surveillance cameras. In the Internet world, you could deter intruders by posting warning banners or copyright notices on your Web site. Some vulnerabilities may prove impossible to fix, and others prohibitively expensive to address. You definitely want to monitor for such vulnerabilities. You might watch for would-be crackers through, for example, intrusion detection products that detect tell-tale signs of attacks. 205 | P a g e Practise secure coding Secure coding practices must be incorporated into all life cycle stages of an application development process. The following minimum set of secure coding practices should be implemented when developing and deploying covered applications: Formalize and document the software development life cycle (SDLC) processes to incorporate major component of a development process: o o o o o o Requirements Architecture and Design Implementation Testing Deployment Maintenance Develop (Build/Configure/Integrate) The development phase implements the requirements and architecture/design decisions. Your security goals can be applied during the development phase. With some high-risk systems, a secure development environment is set up during this phase. This would include the proper policies and procedures to protect the integrity and confidentiality of the code, the designs, and underlying development infrastructure from related attacks such as theft or destruction. The essential part of development is coding, that is, the writing of the actual programming code. Some companies have coding standards -- specific rules for code structure and appearance. Standards can prolong the life of the code, and make it easier to maintain. Writing secure code from the start saves time and money during testing and the remainder of the life cycle. Many organizations are adopting secure coding standards to ensure that the code is secure. To achieve this aim, developers should use defensive programming techniques. Examples of security-related development considerations are: • Identify, in terms of security, the weaknesses and strengths of the programming language. • Put system source code and related configuration files in a secure environment, preferably one isolated from the rest of the network. • Set up a code/component version control system. • Develop operational procedures (based on the CONOP). Ensure that network and systems administrators, partners, customers, and integration firms that deploy the solution or solution components meet the requirements outlined in the technical standards for the mitigation of vulnerabilities. 206 | P a g e Defensive techniques are further detailed in the METASeS publication Building Secure e-Commerce Applications. With the implementation of a standard set of secure coding practices, your organization will have a much easier time understanding the most common risks you deal with and learn the best ways to fix and prevent similar issues in the future33. 1. Secure by Design Today’s worst kinds of application vulnerabilities are realized when malicious actors exploit bugs that allow them to steal, change or delete data. These attacks use vulnerabilities like SQL injection and cross-site scripting, which, while fairly simple to fix, still somehow manage to run rampant and wreak havoc in our software. The solution, which is never easy but will save time and damage later, is to design your applications with security at top of mind. Making your applications secure by design is the number one practice on this list because it’s a prerequisite for the security principles to follow. In Practice: During the design stage, make sure that security policies are implemented within the architecture. Ensure source code analysis is implemented throughout your SDLC, so that vulnerabilities are detected and can be fixed as soon as they’re written. 2. Threat Modeling Determining the greatest threats and risks posed by your applications is a fundamental part of secure code. You most likely won’t be able to fix all issues immediately, all the time, so identifying your most valuable assets and the most severe vulnerabilities will tell you what needs to get fixed and how quickly. In Practice: Perform source code analysis both on applications in their design stage as well as legacy applications or software with legacy code to find all vulnerabilities, before analyzing their risk level. Use a threat modeling tool to automate the process of evaluating and analyzing risk, saving time for the remediation work. 33 Source: Checkmarx, as at https://www.checkmarx.com/2015/07/01/9-secure-coding-practices-you-cantignore/, as on 10th May, 2017. 207 | P a g e 3. Keep Security Simple Complexity makes security easy to ignore and fail. If there are too many separate tools and processes included in properly securing a function, they won’t all be followed. Making the process as simple as possible for all involved will go far in getting the organization as a whole to adopt these principles. In Practice: Reuse components that you know to be trusted. Avoid complex architecture and coding with double negatives (more at OWASP). Centralize your approaches by making the fundamentals part of your design. Integrate your security tools within the developers already-familiar environments, including their IDE, build management, source repository, bug tracking system, etc. 4. Defense in Depth At the same time that we’re making security as simple as possible, we need to practice ‘defense in depth.’ It’s a balance that needs to be weighed by the various risks posed. The principle of defense in depth is all about layering our defense tools in order to minimize the number of holes in our application that would allow different attacks to take place. The idea behind defense in depth, of course, is that if one security layer fails, the next will be there to catch whatever attacks fall through the cracks of the first layer. How many layers and which tools are required are different for each organization. In Practice: Find the best mix of SAST, DAST, Pen-testing, RASP and IAST for your organization, and make sure they’re baked directly into the SDLC. Ensure that your applications Administrative Interface does not allow unauthorized access by non-admins. Use secure development techniques within secure runtime environments. 5. Least Privilege Access within applications needs to be carefully designed so that each account has the appropriate – in this case, the least – amount of privilege necessary for their needs or responsibilities. Consider any applications that offer first-time users default passwords for the initial login session. To make it harder for malicious actors to get their hands on them, make sure each default password is different, complex, and only usable for a limited time. In Practice: Create a data classification system to help easily designates appropriate, role-based privileges for all data. 208 | P a g e Perform access control validations to ensure users are authorized to perform any given task, as well as terminating sessions that don’t pass an authorization check. Centralize the above routines so that any errors or vulnerabilities will be fixed throughout the application. 6. Positive Security Define what is allowed and reject everything else. This model, also called whitelisting, is the only true method of preventing unwanted attacks that weren’t thought of during development. New malware pops up on a regular basis, so it’s already impossible to keep your applications up to date in that sense. With application whitelisting, the attack surface is limited only to the number of risks it has accepted through the earlier discussed practice of threat modeling. In Practice: Never trust user input (a common theme in these practices and one not to be ignored)! To keep in line with the earlier practice of keeping security simple, be sure to use a whitelisting solution that will be easy for admins. 7. Fail Securely Bruce Schneier wrote it perfectly: “ When an ATM fails, it shuts down; it doesn’t spew money out its slot.” Realize that failure is unavoidable and your applications will fail – make sure you (and they) are prepared. Instead, we need to ensure our software is prepared to fail without offering up sensitive data in the process. In Practice: Ensuring that least privilege is followed will help you in failing securely by denying unauthenticated access. If there is an error processing the login information, make sure your application doesn’t disclose any more information than a generic error Always log the failure for further analysis later on to understand the error strategy and see what improvements can be made. 8. Avoid Security by Obscurity Security by Obscurity does NOT work. We’ve seen it fail time and time again, yet some organizations still don’t seem to get it. For example, while demanding your users and employees use strong passwords offers one layer of security by obscurity, you can’t just rely on that. You still need to sanitize inputs, secure your database, and log inconsistencies for later analysis. 209 | P a g e Perhaps one of the best ways to avoid security by obscurity is to assume your source code has already been taken. That would be a worst-case scenario, but we can’t keep holding our fingers crossed hoping a vulnerability won’t be discovered before you can fix it. In Practice: Assume your source code has been compromised and always ensure proper security testing. Threat modeling and defense in depth are two principles that will help in knowing where you’re most vulnerable so you can decide how to move forward. 9 .Complete Remediation Last, yet certainly not least, is the principle of fully understanding and remediating risky vulnerabilities. Only through proper testing and training can an organization truly cut down on their security risks by learning from past mistakes and planning for the future. Completely remediating those vulnerabilities that hold your code back is the only way you can truly move forward in your security program. This is where source code analysis works especially well, both in regards to testing for security issues and tracking the issue fixes. As the OWASP Testing Guide – a highly valuable resource for all application stakeholders – states: Source code analysis and unit tests can validate that the code change mitigates the vulnerability exposed by the previously identified coding defect. The results of automated secure code analysis can also be used as automatic check-in gates for version control, for example software artifacts cannot be checked into the build with high or medium severity coding issues. In Practice: Using a visualized graph such as the one CxSAST offers adds value by saving time and later issues by providing an in-depth analysis of the issues found in your code – and the best locations to fix them for maximum remediation in minimal effort and tampering. Activity 10 Who are the primary users of documentation throughout the SDLC? 210 | P a g e Activity 10 211 | P a g e Activity 10 212 | P a g e Activity 10 Review new and existing risk management technologies to achieve an optimal enterprise risk posture Operations/Maintenance After the system is deployed, you continue to operate and maintain it. From a security perspective, operations and maintenance may include: • Test and migrate to new software versions. Especially important because vulnerability conditions change over time. Patches and service packs will address known vulnerabilities. • Conduct periodic risk review and consult with the business/application owner to assess whether risks have changed. Make appropriate upgrades or downgrades. • Continue to provide as well as strengthen the security awareness program, reminding end users of the things they need to do to maintain security. This is important because new users are added and new vulnerabilities arise continually, and existing users tend to let down their guard . • Conduct periodic vulnerability assessments. Be aware that hackers are discovering new vulnerabilities and devising new threats all the time. It is critical to catch vulnerabilities in a new release before the application is made public. You should perform quarterly to yearly vulnerability assessments, based on the risk profile of applications. It is particularly important to perform vulnerability assessments with new releases of the system, as this is often when new vulnerabilities arise. • Perform auditing, logging, monitoring, archiving. This should include periodic audits of processes and procedures, as well as ongoing review of logs, especially when monitoring for known weaknesses. Risk management is an ongoing, never ending process. Within this process implemented security measures are regularly monitored and reviewed to ensure that they work as planned and that changes in the environment rendered them ineffective. Business requirements, vulnerabilities and threats can change over the time. 213 | P a g e Regular audits should be scheduled and should be conducted by an independent party, i.e. somebody not under the control of whom is responsible for the implementations or daily management of ISMS. Review new and existing ICT security technologies to support secure engineering across the SDLC phases Design a Security Test Plan You should perform a basic check of the components of the system test plan. Security needs to be wrapped into the overall test plan. It should be communicated to the integration and deployment teams. In addition to traditional systems testing, you want to focus on certain specific areas. These include: • Usability/Ergonomics Testing – Checks that security features function, and are reasonably well understood and easy to use. If the security features do not have these characteristics, they will be ignored or will cause problems. Usability/ergonomics is typically applied to applications themselves, but can be applied to security-related matters as well. • Performance Testing – Checks that the system efficiency performs as required. This is traditionally done as part of the regular SDLC. However, as mentioned above, testing after turning on the security-related features -- authentication, encryption, etc. -- is important in determining if system performance is adequate. The impact of security features on performance is often not noticed until after the system is put into production. • Vulnerability Testing – Also known as penetration testing or "ethical hacking", attempts to uncover critical vulnerabilities so that they can be fixed before production. Because vulnerability testing is not part of the traditional SDLC, it is often overlooked. Security controls should be validated. Technical controls are possible complex systems that are to tested and verified. The hardest part to validate is people knowledge of procedural controls and the effectiveness of the real application in daily business of the security procedures. Vulnerability assessment, both internal and external, and Penetration test are instruments for verifying the status of security controls. Information technology security audit is an organizational and procedural control with the aim of evaluating security. The IT systems of most organization are evolving quite rapidly. Risk management should cope with these changes through change authorization after risk re-evaluation of the affected systems and processes and periodically review the risks and mitigation actions. 214 | P a g e Monitoring system events according to a security monitoring strategy, an incident response plan and security validation and metrics are fundamental activities to assure that an optimal level of security is obtained. It is important to monitor the new vulnerabilities, apply procedural and technical security controls like regularly updating software, and evaluate other kinds of controls to deal with zero-day attacks. The attitude of involved people to benchmark against best practice and follow the seminars of professional associations in the sector are factors to assure the state of art of an organization IT risk management practice. Continually assess effectiveness of the information system controls based on risk management practices and procedures Perform Ongoing Vulnerability Monitoring Crackers continually develop new tools and techniques for exploiting vulnerabilities. You need a process for the continual monitoring of new vulnerabilities. A number of organizations, such as Bugtraq, CERT, and METASeS – through its Web Alert service – provide a service that keeps you informed of the latest security vulnerabilities. Because you will not be able to eliminate all vulnerabilities, you will want to regularly monitor holes in your defences. This is typically done through an Intrusion Detection System (IDS). (METASeS conducts "ethical hacking" of clients through an IDS to probe for vulnerabilities.) Because it is impossible to close every hole, a key ability is to react swiftly and effectively in the event of a security incident. For example, a Denial of Service (DoS) attack is nearly impossible to prevent. However, you can monitor for DoS attacks, engineer system redundancies and failovers to mitigate the negative impact of a DoS, and have a plan of action ready in case one occurs. NOTE: Later versions of this report will discuss packaged applications, including those provided by application service providers, and those purchased commercially off-the-shelf (COTS), for example, SAP and PeopleSoft. Improving information management practices is a key focus for many organisations, across both the public and private sectors34. This is being driven by a range of factors, including a need to improve the efficiency of business processes, the demands of compliance regulations and the desire to deliver new services. 34 Source: Step Two, as at http://www.steptwo.com.au/papers/kmc_effectiveim/, as on 10th May, 2017. 215 | P a g e In many cases, ‘information management’ has meant deploying new technology solutions, such as content or document management systems, data warehousing or portal applications. These projects have a poor track record of success, and most organisations are still struggling to deliver an integrated information management environment. Effective information management is not easy. There are many systems to integrate, a huge range of business needs to meet, and complex organisational (and cultural) issues to address. This article draws together a number of ‘critical success factors’ for information management projects. These do not provide an exhaustive list, but do offer a series of principles that can be used to guide the planning and implementation of information management activities. From the outset, it must be emphasised that this is not an article about technology. Rather, it is about the organisational, cultural and strategic factors that must be considered to improve the management of information within organisations. Exploring information management ‘Information management’ is an umbrella term that encompasses all the systems and processes within an organisation for the creation and use of corporate information. In terms of technology, information management encompasses systems such as: web content management (CM) document management (DM) records management (RM) digital asset management (DAM) learning management systems (LM) learning content management systems (LCM) collaboration enterprise search and many more… Information management is, however, much more than just technology. Equally importantly, it is about the business processes and practices that underpin the creation and use of information. It is also about the information itself, including the structure of information (‘information architecture’), metadata, content quality, and more. Information management therefore encompasses: people process technology content 216 | P a g e Each of these must be addressed if information management projects are to succeed. Information management challenges Organisations are confronted with many information management problems and issues. In many ways, the growth of electronic information (rather than paper) has only worsened these issues over the last decade or two. Common information management problems include: Large number of disparate information management systems. Little integration or coordination between information systems. Range of legacy systems requiring upgrading or replacement. Direct competition between information management systems. No clear strategic direction for the overall technology environment. Limited and patchy adoption of existing information systems by staff. Poor quality of information, including lack of consistency, duplication, and out-of-date information. Little recognition and support of information management by senior management. Limited resources for deploying, managing or improving information systems. Lack of enterprise-wide definitions for information types and values (no corporate-wide taxonomy). Large number of diverse business needs and issues to be addressed. Lack of clarity around broader organisational strategies and directions. Difficulties in changing working practices and processes of staff. Internal politics impacting on the ability to coordinate activities enterprise-wide. While this can be an overwhelming list, there are practical ways of delivering solutions that work within these limitations and issues. Ten principles This article introduces ten key principles to ensure that information management activities are effective and successful: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. recognise (and manage) complexity focus on adoption deliver tangible & visible benefits prioritise according to business needs take a journey of a thousand steps provide strong leadership mitigate risks communicate extensively aim to deliver a seamless user experience choose the first project very carefully Each of these is discussed in the sections below. 217 | P a g e Future articles will explore additional principles and guidelines, as well as providing a concrete approach to developing an overarching information management strategy. Principle 1: recognise (and manage) complexity Organisations are very complex environments in which to deliver concrete solutions. As outlined above, there are many challenges that need to be overcome when planning and implementing information management projects. When confronted with this complexity, project teams often fall back upon approaches such as: Focusing on deploying just one technology in isolation. Purchasing a very large suite of applications from a single vendor, in the hope that this can be used to solve all information management problems at once. Rolling out rigid, standardised solutions across a whole organisation, even though individual business areas may have different needs. Forcing the use of a single technology system in all cases, regardless of whether it is an appropriate solution. Purchasing a product ‘for life’, even though business requirements will change over time. Fully centralising information management activities, to ensure that every activity is tightly controlled. All of these approaches will fail, as they are attempting to convert a complex set of needs and problems into simple (even simplistic) solutions. The hope is that the complexity can be limited or avoided when planning and deploying solutions. In practice, however, there is no way of avoiding the inherent complexities within organisations. New approaches to information management must therefore be found that recognise (and manage) this complexity. Organisations must stop looking for simple approaches, and must stop believing vendors when they offer ‘silver bullet’ technology solutions. Instead, successful information management is underpinned by strong leadership that defines a clear direction (principle 6). Many small activities should then be planned to address in parallel the many needs and issues (principle 5). Risks must then be identified and mitigated throughout the project (principle 7), to ensure that organisational complexities do not prevent the delivery of effective solutions. Principle 2: focus on adoption Information management systems are only successful if they are actually used by staff, and it is not sufficient to simply focus on installing the software centrally. 218 | P a g e In practice, most information management systems need the active participation of staff throughout the organisation. For example: Staff must save all key files into the document/records management system. Decentralised authors must use the content management system to regularly update the intranet. Lecturers must use the learning content management system to deliver e-learning packages to their students. Front-line staff must capture call details in the customer relationship management system. In all these cases, the challenge is to gain sufficient adoption to ensure that required information is captured in the system. Without a critical mass of usage, corporate repositories will not contain enough information to be useful. This presents a considerable change management challenge for information management projects. In practice, it means that projects must be carefully designed from the outset to ensure that sufficient adoption is gained. This may include: Identifying the ‘what’s in it for me’ factors for end users of the system. Communicating clearly to all staff the purpose and benefits of the project. Carefully targeting initial projects to build momentum for the project (see principle 10). Conducting extensive change management and cultural change activities throughout the project. Ensuring that the systems that are deployed are useful and usable for staff. These are just a few of the possible approaches, and they demonstrate the wide implications of needing to gain adoption by staff. Principle 3: deliver tangible & visible benefits It is not enough to simply improve the management of information ‘behind the scenes’. While this will deliver real benefits, it will not drive the required cultural changes, or assist with gaining adoption by staff (principle 2). In many cases, information management projects initially focus on improving the productivity of publishers or information managers. While these are valuable projects, they are invisible to the rest of the organisation. When challenged, it can be hard to demonstrate the return on investment of these projects, and they do little to assist project teams to gain further funding. Instead, information management projects must always be designed so that they deliver tangible and visible benefits. 219 | P a g e Delivering tangible benefits involves identifying concrete business needs that must be met (principle 4). This allows meaningful measurement of the impact of the projects on the operation of the organisation. The projects should also target issues or needs that are very visible within the organisation. When solutions are delivered, the improvement should be obvious, and widely promoted throughout the organisation. For example, improving the information available to call centre staff can have a very visible and tangible impact on customer service. In contrast, creating a standard taxonomy for classifying information across systems is hard to quantify and rarely visible to general staff. This is not to say that ‘behind the scenes’ improvements are not required, but rather that they should always be partnered with changes that deliver more visible benefits. This also has a major impact on the choice of the initial activities conducted (principle 10). Principle 4: prioritise according to business needs It can be difficult to know where to start when planning information management projects. While some organisations attempt to prioritise projects according to the ‘simplicity’ of the technology to be deployed, this is not a meaningful approach. In particular, this often doesn’t deliver short-term benefits that are tangible and visible (principle 3). Instead of this technology-driven approach, the planning process should be turned around entirely, to drive projects based on their ability to address business needs. In this way, information management projects are targeted at the most urgent business needs or issues. These in turn are derived from the overall business strategy and direction for the organisation as a whole. For example, the rate of errors in home loan applications might be identified as a strategic issue for the organisation. A new system might therefore be put in place (along with other activities) to better manage the information that supports the processing of these applications. Alternatively, a new call centre might be in the process of being planned. Information management activities can be put in place to support the establishment of the new call centre, and the training of new staff. Principle 5: take a journey of a thousand steps There is no single application or project that will address and resolve all the information management problems of an organisation. 220 | P a g e Where organisations look for such solutions, large and costly strategic plans are developed. Assuming the results of this strategic planning are actually delivered (which they often aren’t), they usually describe a long-term vision but give few clear directions for immediate actions. In practice, anyone looking to design the complete information management solution will be trapped by ‘analysis paralysis’: the inability to escape the planning process. Organisations are simply too complex to consider all the factors when developing strategies or planning activities. The answer is to let go of the desire for a perfectly planned approach. Instead, project teams should take a ‘journey of a thousand steps’. This approach recognises that there are hundreds (or thousands) of often small changes that are needed to improve the information management practices across an organisation. These changes will often be implemented in parallel. While some of these changes are organisation-wide, most are actually implemented at business unit (or even team) level. When added up over time, these numerous small changes have a major impact on the organisation. This is a very different approach to that typically taken in organisations, and it replaces a single large (centralised) project with many individual initiatives conducted by multiple teams. While this can be challenging to coordinate and manage, this ‘thousand steps’ approach recognises the inherent complexity of organisations (principle 1) and is a very effective way of mitigating risks (principle 7). It also ensures that ‘quick wins’ can be delivered early on (principle 3), and allows solutions to be targeted to individual business needs (principle 4). Principle 6: provide strong leadership Successful information management is about organisational and cultural change, and this can only be achieved through strong leadership. The starting point is to create a clear vision of the desired outcomes of the information management strategy. This will describe how the organisation will operate, more than just describing how the information systems themselves will work. Effort must then be put into generating a sufficient sense of urgency to drive the deployment and adoption of new systems and processes. Stakeholders must also be engaged and involved in the project, to ensure that there is support at all levels in the organisation. 221 | P a g e This focus on leadership then underpins a range of communications activities (principle 8) that ensure that the organisation has a clear understanding of the projects and the benefits they will deliver. When projects are solely driven by the acquisition and deployment of new technology solutions, this leadership is often lacking. Without the engagement and support of key stakeholder outside the IT area, these projects often have little impact. Principle 7: mitigate risks Due to the inherent complexity of the environment within organisations (principle 1), there are many risks in implementing information management solutions. These risks include: selecting an inappropriate technology solution time and budget overruns changing business requirements technical issues, particularly relating to integrating systems failure to gain adoption by staff At the outset of planning an information management strategy, the risks should be clearly identified. An approach must then be identified for each risk, either avoiding or mitigating the risk. Risk management approaches should then be used to plan all aspects of the project, including the activities conducted and the budget spent. For example, a simple but effective way of mitigating risks is to spend less money. This might involve conducting pilot projects to identifying issues and potential solutions, rather than starting with enterprise-wide deployments. Principle 8: communicate extensively Extensive communication from the project team (and project sponsors) is critical for a successful information management initiative. This communication ensures that staff have a clear understanding of the project, and the benefits it will deliver. This is a pre-requisite for achieving the required level of adoption. With many projects happening simultaneously (principle 5), coordination becomes paramount. All project teams should devote time to work closely with each other, to ensure that activities and outcomes are aligned. In a complex environment, it is not possible to enforce a strict command-and-control approach to management (principle 1). 222 | P a g e Instead, a clear end point (‘vision’) must be created for the information management project, and communicated widely. This allows each project team to align themselves to the eventual goal, and to make informed decisions about the best approaches. For all these reasons, the first step in an information management project should be to develop a clear communications ‘message’. This should then be supported by a communications plan that describes target audiences, and methods of communication. Project teams should also consider establishing a ‘project site’ on the intranet as the outset, to provide a location for planning documents, news releases, and other updates. Principle 9: aim to deliver a seamless user experience Users don’t understand systems. When presented with six different information systems, each containing one-sixth of what they want, they generally rely on a piece of paper instead (or ask the person next to them). Educating staff in the purpose and use of a disparate set of information systems is difficult, and generally fruitless. The underlying goal should therefore be to deliver a seamless user experience, one that hides the systems that the information is coming from. This is not to say that there should be one enterprise-wide system that contains all information. There will always be a need to have multiple information systems, but the information contained within them should be presented in a human-friendly way. In practice, this means: Delivering a single intranet (or equivalent) that gives access to all information and tools. Ensuring a consistent look-and-feel across all applications, including standard navigation and page layouts. Providing ‘single sign-on’ to all applications. Ultimately, it also means breaking down the distinctions between applications, and delivering tools and information along task and subject lines. For example, many organisations store HR procedures on the intranet, but require staff to log a separate ‘HR self-service’ application that provides a completely different menu structure and appearance. Improving on this, leave details should be located alongside the leave form itself. In this model, the HR application becomes a background system, invisible to the user. Care should also be taken, however, when looking to a silver-bullet solution for providing a seamless user experience. Despite the promises, portal applications do not automatically deliver this. 223 | P a g e Instead, a better approach may be to leverage the inherent benefits of the web platform. As long as the applications all look the same, the user will be unaware that they are accessing multiple systems and servers behind the scenes. Of course, achieving a truly seamless user experience is not a short-term goal. Plan to incrementally move towards this goal, delivering one improvement at a time. Principle 10: choose the first project very carefully The choice of the first project conducted as part of a broader information management strategy is critical. This project must be selected carefully, to ensure that it: demonstrates the value of the information management strategy builds momentum for future activities generates interest and enthusiasm from both end-users and stakeholders delivers tangible and visible benefits (principle 3) addresses an important or urgent business need (principle 4) can be clearly communicated to staff and stakeholders (principle 8) assists the project team in gaining further resources and support Actions speak louder than words. The first project is the single best (and perhaps only) opportunity to set the organisation on the right path towards better information management practices and technologies. The first project must therefore be chosen according to its ability to act as a ‘catalyst’ for further organisational and cultural changes. In practice, this often involves starting with one problem or one area of the business that the organisation as a whole would be interested in, and cares about. For example, starting by restructuring the corporate policies and procedures will generate little interest or enthusiasm. In contrast, delivering a system that greatly assists salespeople in the field would be something that could be widely promoted throughout the organisation. Implementing information technology solutions in a complex and ever-changing organisational environment is never easy. The challenges inherent in information management projects mean that new approaches need to be taken, if they are to succeed. This article has outlined ten key principles of effective information management. These focus on the organisational and cultural changes required to drive forward improvements. The also outline a pragmatic, step-by-step approach to implementing solutions that starts with addressing key needs and building support for further initiatives. A focus on adoption then ensures that staff actually use the solutions that are deployed. 224 | P a g e Of course, much more can be written on how to tackle information management projects. Future articles will further explore this topic, providing additional guidance and outlining concrete approaches that can be taken. Assess and evaluate system compliance with corporate policies and architectures Integrating risk management into system development life cycle35 Effective risk management must be totally integrated into the SDLC. An IT system’s SDLC has five phases: initiation, development or acquisition, implementation, operation or maintenance, and disposal. The risk management methodology is the same regardless of the SDLC phase for which the assessment is being conducted. Risk management is an iterative process that can be performed during each major phase of the SDLC. Table 2-1 Integration of Risk Management into the SDLC[8] SDLC Phases Phase Characteristics Support from Risk Management Activities Phase 1: Initiation The need for an IT system is Identified risks are used to support the expressed and the purpose and development of the system scope of the IT system is requirements, including security documented requirements, and a security concept of operations (strategy) Phase 2: The IT system is designed, The risks identified during this phase can Development or purchased, programmed, be used to support the security analyses Acquisition developed, or otherwise of the IT system that may lead to constructed architecture and design tradeoffs during system development Phase 3: The system security features The risk management process supports Implementation should be configured, enabled, the assessment of the system tested, and verified implementation against its requirements and within its modeled operational environment. Decisions regarding risks identified must be made prior to system operation Phase 4: The system performs its Risk management activities are Operation or functions. Typically the system is performed for periodic system Maintenance being modified on an ongoing reauthorization (or reaccreditation) or basis through the addition of whenever major changes are made to an hardware and software and by IT system in its operational, production 35 Source: Revolvy, as at https://www.revolvy.com/main/index.php?s=IT%20risk%20management&item_type=topic&sr=50, as on 10th May, 2017. 225 | P a g e Phase 5: Disposal changes to organizational processes, policies, and procedures This phase may involve the disposition of information, hardware, and software. Activities may include moving, archiving, discarding, or destroying information and sanitizing the hardware and software environment (e.g., new system interfaces) Risk management activities are performed for system components that will be disposed of or replaced to ensure that the hardware and software are properly disposed of, that residual data is appropriately handled, and that system migration is conducted in a secure and systematic manner NIST SP 800-64 is devoted to this topic. Early integration of security in the SDLC enables agencies to maximize return on investment in their security programs, through: Early identification and mitigation of security vulnerabilities and misconfigurations, resulting in lower cost of security control implementation and vulnerability mitigation; Awareness of potential engineering challenges caused by mandatory security controls; Identification of shared security services and reuse of security strategies and tools to reduce development cost and schedule while improving security posture through proven methods and techniques; and Facilitation of informed executive decision making through comprehensive risk management in a timely manner. This guide[22] focuses on the information security components of the SDLC. First, descriptions of the key security roles and responsibilities that are needed in most information system developments are provided. Second, sufficient information about the SDLC is provided to allow a person who is unfamiliar with the SDLC process to understand the relationship between information security and the SDLC. The document integrates the security steps into the linear, sequential (a.k.a. waterfall) SDLC. The five-step SDLC cited in the document is an example of one method of development and is not intended to mandate this methodology. Lastly, SP 800-64 provides insight into IT projects and initiatives that are not as clearly defined as SDLC-based developments, such as service-oriented architectures, cross-organization projects, and IT facility developments. Security can be incorporated into information systems acquisition, development and maintenance by implementing effective security practices in the following areas.[23] Security requirements for information systems Correct processing in applications Cryptographic controls Security of system files Security in development and support processes Technical vulnerability management 226 | P a g e Information systems security begins with incorporating security into the requirements process for any new application or system enhancement. Security should be designed into the system from the beginning. Security requirements are presented to the vendor during the requirements phase of a product purchase. Formal testing should be done to determine whether the product meets the required security specifications prior to purchasing the product. Correct processing in applications is essential in order to prevent errors and to mitigate loss, unauthorized modification or misuse of information. Effective coding techniques include validating input and output data, protecting message integrity using encryption, checking for processing errors, and creating activity logs. Applied properly, cryptographic controls provide effective mechanisms for protecting the confidentiality, authenticity and integrity of information. An institution should develop policies on the use of encryption, including proper key management. Disk Encryption is one way to protect data at rest. Data in transit can be protected from alteration and unauthorized viewing using SSL certificates issued through a Certificate Authority that has implemented a Public Key Infrastructure. System files used by applications must be protected in order to ensure the integrity and stability of the application. Using source code repositories with version control, extensive testing, production back-off plans, and appropriate access to program code are some effective measures that can be used to protect an application's files. Security in development and support processes is an essential part of a comprehensive quality assurance and production control process, and would usually involve training and continuous oversight by the most experienced staff. Applications need to be monitored and patched for technical vulnerabilities. Procedures for applying patches should include evaluating the patches to determine their appropriateness, and whether or not they can be successfully removed in case of a negative impact. Problem/Modification Identification Phase In this phase, software changes are identified, categorized, and assigned an initial priority ranking. Each software change request is evaluated to determine its classification and handling priority. The classification types of maintenance are: Corrective – Change to the software after delivery to correct defects. The changes may be reported by the "Hot Lines" from the user community. Adaptive – Change to the software after delivery to keep it functioning properly in a changing environment. These changes may be initiated and tracked via the Data Processing Service Request (DPSR) system. Emergency – Unscheduled corrective maintenance required to keep a system operational. Scheduled – Change to the software after delivery on a routine basis to improve performance or maintainability. The changes may be initiated by the users and tracked by the DPSR system. 227 | P a g e Perfective – Change to the software after delivery to improve performance or maintainability. The changes may be initiated by the user and tracked by the DPSR system. Any number of factors can drive the need for software modifications, including: Report of system malfunction Mandatory changes required by new or changed federal or state law New requirements to support business needs Minor enhancement or redesign to improve functionality or replace an obsolete system component Operational system upgrades and new versions of resident software. These factors must be considered when assigning a priority to the modification request. Input to the Problem/Modification Identification Phase of software maintenance is one or more Modification Requests. Process If a modification to the software is required, activities to occur within the maintenance process include: Assign an identification number Categorize the type of maintenance Analyze the modification to determine whether to accept, reject or further evaluate Prioritize the modification according to: Emergency (follow emergency change procedure and integrate into the next schedule release or block of modifications) Mandatory (e.g., legal, safety, payroll) Required (has associated benefits; e.g., productivity gains, new business drivers) Nice to have (lower priority) Assess system maturation and readiness for promotion to the production stage System Efficiency and Effectiveness The performance of the system can be measured by two factors, viz., the efficiency and the effectiveness. The efficiency indicates the manner in which the inputs are used by the system. Being efficient means the system uses inputs in a `right' way. If the input-output ratio is adverse, we say that the system is inefficient though it produces the desired output. 228 | P a g e The effectiveness is the measure for deciding whether the system provides the desired output or not. Being effective means producing the right output in terms of quantity and quality. When the system is ineffective, the system is out of control and it needs a major correction. A system has to be effective and efficient for the highest utility to the user of the system. Broadly speaking, the effectiveness is a measure of the goodness of the output, while the efficiency is a measure of the productivity, i.e., the measure of the output against the input. After the project sponsor or user representative has formally accepted the product, the transition to operational status begins. The procedures identified in the Transition Plan are used to implement the transition process. Stress tests, or other operational tests, may be necessary to confirm a sound installation. The product may require checking to determine tolerances to adverse conditions, failure modes, recovery methods, and specification margins. Training and certification activities are completed, as needed. Any support to be provided by contracted services is checked to ensure the support starts on time. The project team usually provides operational and technical support during the transition. Project team members who have a comprehensive understanding of the product need to be identified as potential support personnel. These individuals may be helpful in providing assistance in the areas of software installation and maintenance, test, and documentation of changes. Technical support may involve the analysis of problems in software components and operational procedures, the analysis of potential enhancements, and vendor supplied upgrades to software components. Transition to full operational status is an event-oriented process not completed until all transition activities have been successfully performed. Support provided by project team personnel is typically withdrawn in a gradual sequence. This aids in the smooth operation of the product and supports user confidence in the product. A formal transfer of all responsibility to the maintenance staff is planned at the conclusion of the transition process. Access to all Project Folder materials, operating documents, identification of any planned enhancements, and other pertinent records are turned over to the maintenance staff. The software access rules must be modified to provide access to the maintenance staff and to remove access from the project team and other temporary users. Programs, files, and other support software must be in the production library and deleted from the test library, where appropriate. For major systems involving multiple organizations or interfaces with other systems, a formal announcement of the transition to production is recommended. The announcement must be distributed to all affected groups, along with names, telephone numbers, and e-mail addresses of the maintenance staff. Maintain Data / Software Administration Data / Software Administration is needed to ensure the input data and output data and data bases are correct and continually checked for accuracy and completeness. This includes ensuring that any regularly scheduled jobs are submitted and completed correctly. Software and data bases are to be maintained at (or near) the current maintenance level. Data / Software Administration tasks and activities include: 229 | P a g e Performing a periodic Verification / Validation of data, correct data related problems; Performing production control and quality control functions (Job submission, checking and corrections); Interfacing with other functional areas for day-to-day checking / corrections; Installing, configuring, upgrading and maintaining data base(s). This includes updating processes, data flows, and objects (usually shown in diagrams); Developing and performing data / data base backup and recovery routines for data integrity and recoverability. Ensure documented properly in the BOM Developing and maintaining a performance plan for online process and data bases Performing configuration/design audits to ensure software, system, parameter configuration are correct Acceptance tests are conducted on a fully integrated system by the project sponsor, the user of the modification package, or a third party designated by the project sponsor. An acceptance test is conducted on the modified system, with software configuration management. Inputs Input for the Acceptance Phase of software maintenance includes: Test Readiness Review report Fully integrated system User Acceptance Test Plan Acceptance test cases Acceptance test procedures Process The steps forming the process for acceptance testing are: Perform acceptance tests at the functional level Perform interoperability testing (to validate any input and output interfaces) Perform regression testing Conduct a Functional Configuration Audit (FCA) The purpose of a FCA is to verify all specified requirements have been met. The audit compares the system’s software elements with the requirements documented in the Requirements Definition Document (RDD), to ensure the modifications address all, and only, those requirements. The results of the FCA must be documented, identifying all discrepancies found, and the plans for the resolution. Control Control of acceptance tests includes: 230 | P a g e Results for the Functional Configuration Audit are reported to ensure all approved functionality is present in the system Confirmation is obtained from the change authority indicating the change has been successfully completed The new system baseline is established The acceptance test documentation is placed under software configuration management control Outputs The outputs of the Acceptance Phase include: New system baseline Functional Configuration Audit Report Acceptance Test Report Updated Project Plan Updated modification request log Collect lessons learned from integration of information security into the SDLC and use to identify improvement actions These items represent several operational practices that fall outside the boundaries of the leading secure SDLC frameworks and models such as Microsoft SDL, BSIMM and OpenSAMM. We discovered that in each of these areas, organizations were making key implementation-level choices that significantly affected how well their secure SDLC program was being executed36. Secure SDLC Lesson 1: Application Catalog Building an application catalog is a critical step towards maintaining governance over a secure SDLC program. The primary purposes of the catalog are to provide teams information on which technologies are in place in the enterprise (Java, .Net, third-party libraries, platforms) and criteria for identifying which applications are mission critical and/or high risk. Plan 36 Source: Optiv, as at https://www.optiv.com/blog/secure-sdlc-lessons-learned-1-application-catalog, as on 10th May, 2017. 231 | P a g e It goes without saying that you can’t truly protect what you don’t know you have. Unsurprisingly, the first step of building the catalog is application discovery. Automated tools are typically used in conjunction with questionnaires, surveys and interviews to collect the base data. Inevitably, the question, “What constitutes an application?” will be raised. Very simply, an application is a set of instructions that requires a running computer process to execute. Common application types include “thick” or compiled programs that run on client and server tiers, web applications, mobile applications, RESTful web services and the like. Additionally, an organization may wish to capture details on internal APIs, service-layer applications and custom ETL processes. Build Once some volume of data is collected, applications can start to be categorized and materially described with attribute values. Application catalogs can take many forms, from spreadsheets to purpose-built database applications. The catalog may link to defect tracking systems, source code repositories and security scanners. Regardless of what technology it’s built on, the catalog should be relatively easy to use, update and query. Attribute-wise, the application catalog should align with the enterprise's risk assessment framework. Each entry in the application catalog should include at a minimum, the application name, application owner, development team, and other stakeholders such as technical leads that would help with incident response and vulnerability management. Include risk descriptors such as criticality, software composition (e.g. key third-party libraries and platforms), number of users, environments installed, platforms, languages, data sensitivities and compliance touchpoints. Descriptors will vary from one organization to the next, but the intent is to equip users with enough information to make informed risk-based decisions. Run Once an application catalog is in place, it should be leveraged to align enterprise security processes and standards with actual security practices. The catalog, when integrated with the rest of the secure SDLC program, will make evident when and where to perform software assurance activities, how to prioritize security-related bug fixes, and enable security teams to measure progress over time. For example, an organization may choose to establish a policy that states, “High risk applications will undergo a third-party penetration test annually.” The catalog should clearly identify “high risk applications” while leaving no room for interpretation or argument. Not all applications will require all security activities. For example, source code security analysis may only be required of the most critical applications and for code changes touching authentication controls. Secure architecture reviews may only be required of new mission-critical systems. As you can see, the application catalog hooks into all aspects of the secure SDLC. It truly becomes the system of record for the enterprise's application security program. Secure SDLC Lesson 2: Assessment Toolchain 232 | P a g e Most organizations would agree that maintaining a fast, predictable flow of planned work (e.g. projects, scheduled changes) that achieves business goals while minimizing the impact of unplanned work (e.g. bug fixes, outages) is the ultimate IT goal. Security assessment activities should be part of planned work, and to accomplish that, the right tools must be selected. As an extension, the tools must be properly configured and integrated into the secure SDLC program to truly be effective. Plan Multiple studies have shown that identifying and remediating security flaws as early as possible in the development lifecycle is the least costly option. This is often referred to as “shifting security left.” Enabling developers to run static code analysis tools from their IDEs to identify possible security weaknesses is one common way to achieve the shift. The integration of dynamic, runtime and interactive assessment tools into various pre-production stages of the SDLC is another common approach. That said, all tools are not created equal. SAST, DAST and IAST tools support a wide variety of serverside and client-side languages and frameworks. Some include features like incremental code scanning and tunable rules. Others offer integration with build processes and defect tracking systems. Consider separating must-haves vs. nice-to-haves, and if possible avoid vendor lock-in. Also understand the capabilities and limitations of the tools in question. Get a feel for where the gaps are and how to address them. There will be gaps, and it’s important to understand what they are. Consider conducting tool bake-offs against a representative subset of your application code to determine the suitability of each tool to your environment. Build Once tool selection is complete, and limitations/capabilities are identified, the next step is tool configuration. This step is absolutely essential for minimizing the amount of false-positives while maximizing code coverage. Consider that oftentimes a wide range of tools with overlapping capabilities is necessary for complete or “manageable” coverage, and confidence that they’re functioning as expected. Identifying the right tools takes time and effort. Subject matter experts are usually necessary to help vet and verify issues identified and tune rulesets. Scanners may not support legacy code, and sometimes re-platforming is a less costly option. On the flip side, scanners can lag behind the latest available frameworks and languages. In both cases, code quality tools and custom test scripts are used to fill the gap in security capability, especially for teams doing continuous integration/continuous deployment. Run Once the toolchain is operational, its output should obviously be consumed in some manner. For instance, output from security scanners embedded in test and staging environments will typically feed into defect tracking systems. Security issues caught earlier in the cycle may not. It’s important though to consider recording the source/stage where each vulnerability was identified, and by what tool. We will visit this question again when we talk about metrics. 233 | P a g e Based on security thresholds defined in the SDLC security standards, security gates will be implemented to break the build/release process when issues of a certain severity or higher are identified by security tools. Additionally, because security testing may not be wired in series with the release workflow, a process to address issues caught by parallel scans and out-of-band penetration tests should be defined. The end goal is to build a reliable and trustworthy toolchain with quality automated tools that gives sufficiently wide coverage across the application portfolio. To fill the remaining gaps, manual testing and other controls will be required. Secure SDLC Lesson 3: Knowledge Management The term “knowledge management” (KM) refers to using vulnerability mining to turn remediation into lessons learned. Essentially this involves taking knowledge from security remediation activities and placing it within a KM repository that developers, architects and other stakeholders can access. By sharing remediation information across teams, an organization can remove or reduce intelligence silos that contribute to recurring and familiar software bugs. Plan After performing applications assessments and other security testing activities for a time, there should be enough remediation data within your defect tracking system to start pulling out the most common security-related coding mistakes. This assumes that security-related bugs are flagged as such. If your organization isn’t already flagging or tagging defects this way, now is the time to start. Consider also mining qualifying bugs by feature or functional areas like authentication, and/or by vulnerability types like lack of input validation. If possible, separate results by language and/or platforms used. Some data normalization may be required to make this easier. Sort by the number of bugs discovered in each category, and focus on documenting those areas first. Build Again, the end goal for building a KM solution is to store company-specific secure coding best practices and remediation techniques as proactive guidance for development teams. A centralized, accessible location such as a Wiki is well-suited for this task. Content typically will include links to relevant security standards, sample code and design templates for things like tying an application’s authentication into the corporate SSO. By defining coding standards around approved enterprise architecture components (e.g. libraries, platforms), architects and developers can gain confidence when developing on secure-by-default frameworks and patterns. Alternatively, developers could dig into the bug tracking solution to find other examples of the bugs, and see how they were fixed, but a curated central knowledge base is very effective. It takes time, but it doesn’t cost product dollars, doesn’t interfere with the build cycle, and it saves a lot more time later when other developers encounter similar issues. 234 | P a g e Run Operationally, someone has to take ownership of selecting and publishing this information. For example, when a vulnerability is identified and remediated, a developer should draft up remediation guidance and dump it into the KM solution. Leverage a workflow so a lead developer or other SME can approve the content, make sure comments are adequate to describe the issue, what the remediation was for, include example code, etc. Teams should take advantage of the KM solution to proactively watch out for the same mistakes other teams have made. Leverage things like tags, keywords and filters to make the pool of historical knowledge searchable. In the end, the system provides developers assurance that if they’re programming in a certain known-good way, they’re aligned with the organization’s definition of secure development. Implemented correctly, KM solutions serve as a continuous feedback loop that helps improve code quality at the source. This is another great example of shifting security left, and as mentioned in an earlier post in this series, that can mean significantly reducing both remediation costs and security risk. Secure SDLC Lesson 4: Metrics As the secure SDLC program matures, vulnerabilities should be caught and remediated earlier in the lifecycle. To know if the program is truly working, organizations must capture metrics. The specific metrics chosen should support and align with the organization’s business objectives and risk management program. Plan Security metrics related to the SDLC are best captured at security checkpoints. These checkpoints or gates may include in-IDE static analysis, code commit analysis, build-time static-analysis, manual code review, dynamic scanning in QA/integration test, and pre- and post-production penetration testing. Internal and external bug bounty programs may also be included as post-production options. By capturing which checkpoint or tool was used to discover which security defects, you will be able to track trends across your application portfolio. In theory, as the secure SDLC program matures, more security bugs should be caught early in the software lifecycle. This metric will help verify this in practice. In addition, proper metrics will help identify toolchain issues, or conversely, justify their expense. For example, if your static analysis tools fail to capture security defects that surface during penetration testing, then there may be a problem in code coverage or a scanner ruleset. Build Beyond tracking the discovery point, there are two main classes of key performance indicators (KPIs): efficiency and risk (though some indicators may fall in the gray area between). 235 | P a g e Each KPI may be filtered by vulnerability type, development team or business area, phase of SDLC discovered, etc., and is often reported per time period. Efficiency indicators may already be available in your bug tracking system. These may include: Time to Remediate (TTR) – how long between when a specific vulnerability is first identified and when it’s fully remediated Average TTR – TTR per time period Current/Average Remediation Queue Size – how much technical security debt exists Velocity – bug fixes completed per time period Pipeline Stress – how many requests for things like manual testing or code review were expedited Other indicators can be designed to track efficiency in security operations, like time to assign an AppSec resource for internal assurance services, time to complete and so on. Risk indicators describe areas specific to the confidentiality, integrity and availability of applications. Coverage – the number of applications per assurance activity (code scan, dynamic analysis) per time period; applications can be ranked according to risk or mission criticality Top Vulnerability Types – per time period Rate of Recurrence – how often known defects come back Churn – how many times a specific vulnerability was incorrectly remediated Composite Risk Rating – often shown graphically, this is a somewhat arbitrary visualization of business risk, defined by something similar to: vulnerability severity x defect count x application risk rating Security Defect Ratio - number of security defects divided by the total number of defects These metrics are usually presented on some form of dashboard, usually with capabilities for drill down and trend reporting. Remember though that the technologies used to implement KPIs are much less important than the information they’re intended to convey. Avoid developing KPIs and visualizations that bring no value to your secure SDLC program. Run Over time, there should be a reduction in post-release vulnerabilities, which again are the most costly to remediate and pose the most risk to the organization. Expect a downward trend in bugs caught later in the SDLC as the program matures. Additionally, vulnerabilities discovered in-cycle should be remediated more quickly. When unexpected indicator values are observed, root cause analysis is often required to address the issue. For example, if severe vulnerabilities continue to be found by an external bug bounty program, then clearly something upstream isn’t working. Properly designed metrics provide a great way to measure the effectiveness of the secure SDLC program over time, and also provide useful feedback when aspects of the program are tweaked. Capturing key indicators affords organizations the ability to experiment with new vendor tools and alternate approaches to testing, and to determine the impact of different types and sources for developer training. 236 | P a g e In short, metrics can take much of the guesswork out of knowing how well your secure SDLC program is working. Secure SDLC Lesson 5: Personnel It’s no secret that finding and retaining dependable, well-trained application security professionals is a serious challenge, and has been for years. Part of the problem is that the breadth and depth of AppSec knowledge is rather astronomical; one could argue that it’s exponentially wider than network security and grows at a much faster rate. Based on what I’ve seen, teams tend to be perpetually short-staffed and undertrained. Furthermore, many companies struggle with how best to build out their AppSec capabilities. Should application scanning and testing activities funnel through an AppSec team, or should developers be able to launch scans on demand and only engage AppSec SMEs when needed? How much and what pieces of the secure SDLC program should be outsourced? Plan Considering the current state of things, there is a tendency for organizations, especially those following Agile and DevOps principles, to have an over-reliance on automated security tools. It’s really no wonder that severe security issues still make it to production today. When secure SDLC programs are built too heavily on technology and too thin on trained professionals, they set themselves up for real trouble. In a recent client discussion regarding security policies and standards, one stakeholder admitted their mantra was, “Tools, not rules!” My response was, “That’s great. Now show me how closely your tools align with your security requirements.” The reality is that automated tools have limitations, and relying on them too much is analogous to organizations trying to outsource risk to third-party providers. It’s misplaced trust. The point here is tools are no substitute for skilled subject matter experts, which in turn are absolutely essential to a successful secure SDLC program. Build Just as point-and-click scanners alone are insufficient, leaning too much on too few individuals can lead to constraints and, even worse, burn-out. One way to address the resource shortage is to “train up” more developers into AppSec. Unfortunately, finding sources of relevant, comprehensive, professional grade AppSec training is relatively difficult these days. There are many options, from onsite/offsite ILT and on-demand CBT to online webinars and videos. However, as it turns out, developers (and many existing security professionals) actually tend to learn best though more informal sources like blogs, feeds and similar online sources. Consider integrating some of these non-standard sources into the training curriculum. Additionally, training folks in offensive security can help them code defensively. Again, there are a multitude of choices available, but no single source that would be considered comprehensive. Consider compiling a list of resources that best fit your teams’ needs and are tailored for each role. 237 | P a g e Run Knowing if your organization has the right personnel in the right places can be made evident through secure SDLC metrics, as mentioned earlier in this blog series. It can also be measured by observing how much your teams are leveraging your knowledge management solution. Ongoing training should not be neglected. Plan for periodic refresher courses, and consider incorporating training and even certifications into role-specific performance plans. As application security is such a moving target, recurring training just makes sense anyway. Though developers tend to get security concepts, they still struggle with connecting conceptual knowledge to prescriptive secure coding practices. By building out your organization’s AppSec capabilities through talent acquisition, training and skills development, you will be well equipped to help them bridge that gap. Conclusion Secure SDLC programs tend to be unique to each organization. Application catalogs, assessment toolchains, knowledge management solutions and metrics may be similar from one company to the next, but will often be implemented on vastly disparate technologies. Organizational structure, culture, industry, and many other determining factors will influence how you ultimately develop and implement a secure SDLC program that is truly your own. Activity 11 Why are lessons learned documented? 238 | P a g e Activity 11 239 | P a g e Activity 11 Collect, analyse and report performance measures Ensuring system security can seem an overwhelming job, given the complexity of technologies, the wealth of new applications continually entering the marketplace, and the growing number of attacks on corporations from external intruders. You will never too able to provide perfect security for your organization. However, you can significantly improve security, and save a great deal of time and effort along the way, by marrying security to every phase of the SDLC. As a part of any organizations well defined SDLC process, the development of documentation specific to the system should be outlined. The documentation would outline the system from development to its’ production state. The documentation may include items identified below37. • system functional requirements, 37 Source: SANS, as at https://www.sans.org/reading-room/whitepapers/awareness/facets-informationsecurity-program-1343, as on 10th May, 2017. 240 | P a g e • database software configurations, • data dictionary, • operating system configurations, • user application configuration, • system architecture (physical), • data flow (logical), • system interconnections, • user manuals, • system security plan, • a disaster recovery/business continuity plan, • security test plan, • certification statement, and • any service level agreements, memorandums of understanding, or memorandums of agreement that was required for the system. The documentation will support the organizations information security program through its availability allowing authorized and qualified individuals the ability to understand the system configurations and operational state. This assists problem isolation reducing system downtime and provides a baseline for the development of enhancements for the system in the future. Having the right documentation available keeps an organization from depending on the individual(s) who developed the system. The system owner is the party responsible to ensure that the documentation is developed, maintained, and made available to the appropriate people. Activity 12 During which stage of the software development life cycle should security be implemented? (a) Development (b) Project initiation (c) Deployment 241 | P a g e Activity 12 (d) Installation In which software development life cycle phase do the programmers and developers become deeply involved and do the majority of the work? (a) System Design Specifications (b) Software Development (c) Operation and Maintenance (d) Functional Design Analysis and Planning Which of the following is a valid system development methodology? (a) The spring model (b) The spiral model (c) The production model (d) The Gantt model What is the process of cataloging all versions of a component configuration called? (a) The configuration library (b) The component library (c) The catalog database (d) The software component library 242 | P a g e Information Technology ICTNWK510 Develop, implement and evaluate system and application security ICTNWK510 DEVELOP, IMPLEMENT AND EVALUATE SYSTEM AND APPLICATION SECURITY Develop system and application security Implement system and application security Evaluate system and application security 1 2 SIX PHASES OF THE SYSTEM DEVELOPMENT LIFE CYCLE SYSTEM DEVELOPMENT LIFE CYCLE (SDLC) • Preliminary Investigation • Assesses feasibility and practicality of system • System Analysis • Study old system and identify new requirements • Defines system from user's view • System Design • Design new/alternative system • Defines system from technical view 3 4 SDLC PHASES SIX PHASES OF THE SYSTEM DEVELOPMENT LIFE CYCLE Preliminary Investigation • System Development • New hardware and software is acquired, developed, and tested System Analysis System Operation & Maintenance • System Implementation • System installation and training • System Operation & Maintenance System Implementation n • Daily operation System Design • Periodic evaluation and updating 5 System Development 6 PHASE 2: SYSTEM ANALYSIS PHASE 1: PRELIMINARY INVESTIGATION • Determine if a new system is needed • In depth study of the existing system to determine what the new system should do. • Three primary tasks: • Expand on data gathered in Phase 1 • Define the problem • By observation and interview, determine what information is needed by whom, when, where and why • Suggest alternative solutions • Prepare a short report 7 • In addition to observation and interviews, examine: • Formal lines of authority (org chart) • Standard operating procedures • How information flows • Reasons for any inefficiencies 8 PHASE 2: SYSTEM ANALYSIS DOCUMENTATION PRODUCED PHASE 2: SYSTEM ANALYSIS TOOLS USED • Checklists - list of questions • Top-down analysis - start with top level components, break down into smaller parts through each successive level • Complete description of current system and its problems • Requirements for for new system including: • Subject • Grid charts - to show relationship between inputs and outputs • Scope • System flowcharts - charts flow of input data, processing, and output which show system elements and interactions • Benefits 9 • Objectives 10 • Possible development schedule PHASE 3: SYSTEM DESIGN PHASE 3: SYSTEM DESIGN TOOLS USED • Uses specifications from the systems analysis to design alternative systems • Computer-Aided Software Engineering (CASE) tools are software-based products designed to help automate the production of information systems. • Evaluate alternatives based upon: • Examples: • Economic feasibility - Do benefits justify costs? • Technical feasibility - Is reliable technology and training available? • Operational feasibility - Will the managers and users support it? 11 • • • • • • Diagramming Tools Data Repositories Prototyping Tools Test Data Generators Documentation Tools Project Management Tools 12 PHASE 3: SYSTEM DESIGN DOCUMENTATION PRODUCED PHASE 4: SYSTEM DEVELOPMENT • Build the system to the design specifications • System Design Report • Develop the software • Describe Alternatives including: • Purchase off-the-shelf software OR • Write custom software • Inputs/Outputs • Processing • Storage and Backup • Acquire the hardware • Test the new system • Recommend Top Alternative based upon: • System Fit into the Organization • Flexibility for the future • Costs vs. benefits • Module (unit) test - tests each part of system • Integration testing - tests system as one unit • Create manuals for users and operators 13 14 PHASE 5: SYSTEM IMPLEMENTATION TYPES OF CONVERSION PHASE 5: SYSTEM IMPLEMENTATION • Direct/plunge/crash approach – entire new system completely replaces entire old system, in one step • Convert from old system to new system • Parallel approach - both systems are operated side by side until the new system proves itself • Train users • Pilot approach - launched new system for only one group within the business -- once new system is operating smoothly, implementation goes company-wide • Compile final documentation • Evaluate the new system • Phased/incremental approach - individual parts of new system are gradually phased-in over time, using either crash or parallel for each piece. 16 15 PHASE 5: SYSTEM IMPLEMENTATION PHASE 6: OPERATIONS & MAINTENANCE • Types of changes: • User Training • • • • • • Ease into system, make them comfortable, and gain their support • Most commonly overlooked • Can be commenced before equipment delivery • Outside trainers sometimes used 17 Physical repair of the system Correction of new bugs found (corrective) System adjustments to environmental changes Adjustments for users’ changing needs (adaptive) Changes to user better techniques when they become available (perfective) 18 DELIVERABLES OF THE SDLC PHASE 6: OPERATIONS & MAINTENANCE Approved Feasibility Study Preliminary Investigation • Evaluation Methods Problem Specifications System Analysis • Systems audit - performance compared to original specifications System Design • Periodic evaluation - “checkups” from time to time, modifications if necessary Abort Project Goto next phase Goto Previous phase Design Specifications System Development Begin building new system Coded and Tested System System Implementation System converted Users trained System Maintenance Operational System Documentation completed 19 20 Bespoke Applications Vs. Commercial Applications Application Development internal use: • Bespoke, customized, one-off application •Audience is not so great: (Users, developers, test) Vulnerabilities are not discovered too quickly by users. Vulnerabilities are discovered by hackers, they actively look for them. INTEGRATION INTO THE SDLC (SOFTWARE DEVELOPMENT LIFE CYCLE) 21 Bespoke Applications Vs. Commercial Applications 22 COMPLEXITY VS SECURITY Bespoke application = Small audience = Less chance of vulnerabilities being discovered This is unlike, Say Microsoft XP 210 Million copies sold (http://www.forbes.com/ As Functionality and May2004) increase security hence complexity First Line of Defense: decreases. Integrating security into functionality at design time Is easier and cheaper. The Developer: •Writes the code. •Understands the problem better than anyone! •Has the skill set. •More effective and efficient in providing a solution “100 Times More Expensive to Fix Security Bug at Production Than Design” – IBM Systems Sciences Institute 23 It also costs less in the long-term. -maintenance cost 24 A FEW FACTS AND FIGURES: GROWTH OF THREAT: GROWTH IN THE TOOLS AVAILABLE. How Many Vulnerabilities Are Application Security Related? 25,000 Hacker Tools 20,000 15,000 10,000 5,000 Categories: • Binder • Carding • Cracking Tool • Flooder • Key Generator • Mail Bomber • Mailer • Misc Tool • Nuker • Packer • Password Cracker • Password Cracking Word List • Phreaking Tool • Port Scanner • Probe Tool • Sniffer • Spoofer • Trojan • Trojan Creation Tool • Virus Creation Tool • Virus Source • Virus Tutorial • War Dialer 19 80 19 81 19 82 19 83 19 84 19 85 19 86 19 87 19 88 19 89 19 90 19 91 19 92 19 93 19 94 19 95 19 96 19 97 19 98 19 99 20 00 20 01 20 02 20 03 20 04 0 Year 25 Source: PestPatrol.com26 A FEW FACTS AND FIGURES (CONTD) IF CARS WERE BUILT LIKE APPLICATIONS…. • Interesting Statistics – Employing code review • IBM Reduces 82% of Defects Before Testing Starts • HP Found 80% of Defects Found Were Not Likely To Be Caught in Testing • 100 Times More Expensive to Fix Security Bug at Production Than Design” – IBM Systems Sciences Institute • Promoting People Looking at Code 1. 70% of all cars would be built without following the original designs and blueprints.The other 30% would not have designs. 2. Car design would assume that safety is a function of road design and that all drivers were considerate, sober and expert drivers. 3. Cars would have no airbags, mirrors, seat belts, doors, roll-bars, sideimpact bars, or locks, because no-one had asked for them. But they would all have at least six cup holders. 4. 5. Not all the components would be bolted together securely and many of them would not be built to tolerate even the slightest abuse. Safety tests would assume frontal impact only. Cars would not be roll tested, or tested for stability in emergency maneuvers, brake effectiveness, side impact and resistance to theft. 6. Many safety features originally included might be removed before the car was completed, because they might adversely impact performance. • Improvement Earlier in SDLC • Fix at Right Place; the Source • Takes 20% extra time – payoff is order of magnitude more. 28 27 - Denis Verdon Ref: http://ganssle.com/Inspections.pdf HOW DO WE DO IT? IF CARS WERE BUILT LIKE APPLICATIONS…. 7. 70% of all cars would be subject to monthly recalls to add major components left out of the initial production. The other 30% wouldn’t be recalled, because no-one would sue anyway. 8. The after-market for safety devices would include such useful products as training wheels, screen doors, elastic seatbelts and devices that would restrict the car’s top speed to 3mph, if found to be unsafe (which would be always). 9. Useful safety could be found, but could only be custom retro-fitted, would take six months to fit and would cost more than the car itself. 10. A NCT/MOT inspection would consist of counting the wheels and making recommendations on wheel quantity. 11. Your only warning indicator would be large quantities of smoke and flame in the cab. 12. You could only get insurance from one provider, it would be extremely expensive, require a duplicate NCT/MOT inspection, and you might still never be able to claim against the policy. - Denis Verdon 29 • Security Analyst: • Get involved early in SDLC. Security is a function of the asset we want to secure, what's it worth? • Understanding the information held in the application and the types of users is half the battle. • Involve an analyst in the design phase and thereafter. • Developer: • Embrace secure application development. (Educate) • Quality is not just “Does it work” Security is a measure of quality also. 30 Software security tollgates in the SDLC HOW DO WE DO IT? (CONTD) Iterative approach • QA: • Security vulnerabilities are to be considered bugs, the same way as a functional bug, and tracked in the same manner. Security requirements Risk analysis • Managers: Static analysis (tools) Design Review Penetration testing Risk-based security tests • Factor some time into the project plan for security. • Consider security as added value in an application. – $1 spent up front saves $10 during development and $100 after release 31 Requirements and use cases Design Test plans Code Test results Field feedback Code Review APPLICATION SECURITY RISK CATEGORIZATION APPLICATION SECURITY PROJECT PLAN • Goal • Define the plan to ensure security at the end • More security for riskier applications • Ideally done at start of project • Ensures that you work the most critical issues first • Can also be started before or after development is complete • Scales to hundreds or thousands of applications • Based on the risk category • Tools and Methodology • Identify activities at each phase • Security profiling tools can gather facts • Necessary people and expertise required • Size, complexity, security mechanisms, dangerous calls • Who has responsibility for risks • Questionnaire to gather risk information • Ensure time and budget for security activities • Asset value, available functions, users, environment, threats • Risk-based approach 32 33 • Establish framework for establishing the “line of sight” 34 • Evaluates likelihood and consequences of successful attack APPLICATION SECURITY REQUIREMENTS TAILORING • Get the security requirements and policy right DESIGN REVIEWS • Better to find flaws early • Security design reviews • Start with a generic set of security requirements • • • • Must include all security mechanisms Must address all common vulnerabilities Can be use (or misuse) cases Should address all driving requirements (regulation, standards, best practices, etc.) • Check to ensure design meets requirements • Also check to make sure you didn’t miss a requirement • Assemble a team • Experts in the technology • Security-minded team members • Tailoring examples… • Specify how authentication will work • Detail the access control matrix (roles, assets, functions, permissions) • Define the input validation rules • Choose an error handling and logging approach 35 • Do a high-level penetration test against the design • Be sure to do root cause analysis on any flaws identified 36 SOFTWARE VULNERABILITY ANALYSIS APPLICATION SECURITY TESTING • Find flaws in the code early • Identify security flaws during testing • Many different techniques • Static (against source or compiled code) • Security focused static analysis tools • Develop security test cases • Peer review process • Based on requirements • Formal security code review • Be sure to include “negative” tests • Dynamic (against running code) • Scanning • Test all security mechanisms and common vulnerabilities • Penetration testing • Goal • Ensure completeness (across all vulnerability areas) 37 • Ensure accuracy (minimize false alarms) APPLICATION SECURITY DEFECT TRACKING AND METRICS • “Every security flaw is a process problem” • Flaws feed into defect tracking and root cause analysis 38 CONFIGURATION MANAGEMENT AND DEPLOYMENT • Ensure the application configuration is secure • Tracking security defects • Find the source of the problem • Bad or missed requirement,design flaw, poor implementation, etc… • Security is increasingly “data-driven” • XML files, property files, scripts, databases, directories • ISSUE: can you track security defects the same way as other defects • How do you control and audit this data? • Metrics • What lifecycle stage are most flaws originating in? • What security mechanisms are we having trouble implementing? • What security vulnerabilities are we having trouble avoiding? 39 • Design configuration data for audit • Put all configuration data in CM • Audit configuration data regularly • Don’t allow configuration changes in the field 40 WHAT NOW? "So now, when we face a choice between adding features and resolving security issues, we need to choose security." -Bill Gates The user's going to pick dancing pigs over security every time. -Bruce Schneier If you think technology can solve your security problems, then you don't understand the problems and you don't understand the technology. -Bruce Schneier Using encryption on the Internet is the equivalent of arranging an armored car to deliver credit-card information from someone living in a cardboard box to someone living on a park bench. -Gene Spafford 41 THE SECURITY SYSTEMS DEVELOPMENT LIFE CYCLE (SECSDLC) 42 THE SECURITY SYSTEMS DEVELOPMENT LIFE CYCLE (SECSDLC) INVESTIGATION IN THE SECSDLC • May differ in several specifics, but overall methodology is similar to the SDLC • SecSDLC process involves: • Often begins as directive from management specifying the process, outcomes, and goals of the project and its budget • Frequently begins with the affirmation or creation of security policies • Teams assembled to analyze problems, define scope, specify goals and identify constraints • Identification of specific threats and the risks that they represent • Subsequent design and implementation of specific controls to counter those threats and assist in the management of the risk those threats pose to the organization • Feasibility analysis determines whether the organization has resources and commitment to conduct a successful security analysis and design 44 43 ANALYSIS IN THE SECSDLC RISK MANAGEMENT • A preliminary analysis of existing security policies or programs is prepared along with known threats and current controls • Risk Management: process of identifying, assessing, and evaluating the levels of risk facing the organization • Includes an analysis of relevant legal issues that could affect the design of the security solution • Specifically the threats to the information stored and processed by the organization • To better understand the analysis phase of the SecSDLC, you should know something about the kinds of threats facing organizations • In this context, a threat is an object, person, or other entity that represents a constant danger to an asset • Risk management begins in this stage 45 KEY TERMS 46 THREATS TO INFORMATION SECURITY • Attack: deliberate act that exploits a vulnerability to achieve the compromise of a controlled system • Accomplished by a threat agent that damages or steals an organization’s information or physical asset • Exploit: technique or mechanism used to compromise a system • Vulnerability: identified weakness of a controlled system in which necessary controls are not present or are no longer effective 47 48 RISK MANAGEMENT SOME COMMON ATTACKS • Use some method of prioritizing risk posed by each category of threat and its related methods of attack • Malicious code • Spoofing • Hoaxes • Man-in-the-middle • Back doors • Spam • Password crack • Mail bombing • Brute force • Sniffer • Dictionary • Social engineering • Denial-of-service (DoS) and distributed denial-of-service (DDoS) • Buffer overflow • To manage risk, you must identify and assess the value of your information assets • Risk assessment assigns comparative risk rating or score to each specific information asset • Risk management identifies vulnerabilities in an organization’s information systems and takes carefully reasoned steps to assure the confidentiality, integrity, and availability of all the components in organization’s information system • Timing 50 49 SECURITY MODELS DESIGN IN THE SECSDLC • Security managers often use established security models to guide the design process • Design phase actually consists of two distinct phases: • Logical design phase: team members create and develop a blueprint for security, and examine and implement key policies • Physical design phase: team members evaluate the technology needed to support the security blueprint, generate alternative solutions, and agree upon a final design • Security models provide frameworks for ensuring that all areas of security are addressed • Organizations can adapt or adopt a framework to meet their own information security needs 52 51 POLICY SETA • A critical design element of the information security program is the information security policy • Another integral part of the InfoSec program is the security education and training program • Management must define three types of security policy: • SETA program consists of three elements: security education, security training, and security awareness • General or security program policy • Purpose of SETA is to enhance security by: • Issue-specific security policies • Improving awareness • Systems-specific security policies • Developing skills and knowledge • Building in-depth knowledge 53 54 DESIGN MANAGERIAL CONTROLS • Attention turns to the design of the controls and safeguards used to protect information from attacks by threats • Address the design and implementation of the security planning process and security program management • Three categories of controls: • Management controls also address: • Managerial • Risk management • Operational • Security control reviews • Technical 55 56 OPERATIONAL CONTROLS TECHNICAL CONTROLS • Cover management functions and lower level planning including: • Address those tactical and technical issues related to designing and implementing security in the organization • Disaster recovery • Incident response planning • Technologies necessary to protect information are examined and selected • Operational controls also address: • Personnel security • Physical security • Protection of production inputs and outputs 57 58 CONTINGENCY PLANNING PHYSICAL SECURITY • Essential preparedness documents provide contingency planning (CP) to prepare, react and recover from circumstances that threaten the organization: • Physical Security: addresses the design, implementation, and maintenance of countermeasures that protect the physical resources of an organization • Physical resources include: • Incident response planning (IRP) • People • Disaster recovery planning (DRP) • Hardware • Business continuity planning (BCP) • Supporting information system elements 59 60 IMPLEMENTATION IN THE SECSDLC INFOSEC PROJECT TEAM • Security solutions are acquired, tested, implemented, and tested again • Should consist of individuals experienced in one or multiple technical and non-technical areas including: • Personnel issues are evaluated and specific training and education programs conducted • Perhaps most important element of implementation phase is management of project plan: • Champion • Team leader • Security policy developers • Risk assessment specialists • Planning the project • Security professionals • Supervising tasks and action steps within the project • Systems administrators • Wrapping up the project • End users 62 61 STAFFING THE INFOSEC FUNCTION • INFOSEC PROFESSIONALS Each organization should examine the options for staffing of the information security function 1. Decide how to position and name the security function 2. Plan for proper staffing of information security function 3. Understand impact of information security across every role in IT 4. Integrate solid information security concepts into personnel management practices of the organization • It takes a wide range of professionals to support a diverse information security program: • Chief Information Officer (CIO) • Chief Information Security Officer (CISO) • Security Managers • Security Technicians • Data Owners • Data Custodians • Data Users 64 63 CERTIFICATIONS MAINTENANCE AND CHANGE IN THE SECSDLC • Many organizations seek professional certification so that they can more easily identify the proficiency of job applicants: • CISSP • SSCP • Once information security program is implemented, it must be operated, properly managed, and kept up to date by means of established procedures • GIAC • SCP • If the program is not adjusting adequately to the changes in the internal or external environment, it may be necessary to begin the cycle again • ICSA • Security + • CISM 65 66 MAINTENANCE MODEL ISO MANAGEMENT MODEL • While a systems management model is designed to manage and operate systems, a maintenance model is intended to focus organizational effort on system maintenance: • One issue planned in the SecSDLC is the systems management model • ISO management model contains five areas: • External monitoring • Fault management • Internal monitoring • Planning and risk assessment • Configuration and name management • Vulnerability assessment and remediation • Accounting management • Readiness and review • Performance management • Vulnerability assessment • Security management 67 SECURITY MANAGEMENT MODEL 68 SECURITY PROGRAM MANAGEMENT • Fault Management involves identifying and addressing faults • Configuration and Change Management involve administration of components involved in the security program and administration of changes • Accounting and Auditing Management involves chargeback accounting and systems monitoring • Performance Management determines if security systems are effectively doing the job for which they were implemented • Once an information security program is functional, it must be operated and managed • In order to assist in the actual management of information security programs, a formal management standard can provide some insight into the processes and procedures needed • This could be based on the BS7799/ISO17799 model or the NIST models described earlier 69 70 RISK ASSESSMENT RISK ASSESSMENT • The risk assessment process - converting subjective risks into objective harms. • Determining the level of risk is achieved by comparing the relationship between the threats to information and assets and the known security weaknesses or vulnerability of information technology systems. Harms to your information system can be assessed, analysed and measured. Risk is assessed against the likelihood and consequence of compromising: • Confidentiality • The level of acceptable risk is a managerial decision based on the information and recommendations provided in the risk assessment. • Integrity • Availability of your information 71 72 RISK ASSESSMENT RISK ASSESSMENT Discover environmental data: • Establish the Context • What data do you hold? • Define relationship with other systems. • Where is the information? • Identify assets. • Where does the data reside ? • Establish risk criteria. • Interfaces ? • Risk Identification • Who has access to your information? • Identify the risks to be managed. • What are the boundaries of your system? • Determine what to protect against (Threats). • Determine who to protect against. • Is information systems security about computers or Information ? 73 74 RISK ASSESSMENT RISK ASSESSMENT • Risk Analysis • Risk Evaluation and Treatment • Analyze risks to be managed. • Compare assessed risks against risk criteria. • Estimate likelihood and consequence. • Consider treatment options. • Determine context against management/control measures. • Assess existing/proposed security measures. • Recommendations • Determine vulnerability and acceptable risk. • Identify the steps to be taken to manage the accepted or residual risks. 75 76 HIGH SECURITY ENVIRONMENTS HIGH SECURITY ENVIRONMENTS • Characterized by robust security plans. • Information Security principles are the key. • “The Need to Know” Principle. • “The availability of information limited to those who need to use or access the information to do their work”. 77 78 HIGH SECURITY ENVIRONMENTS SECURITY IN DEPTH • Awareness - expectations about use and care of information. • Protective security procedures and measures must be understood by those who will implement and practice them. • Concept of Security in Depth is a key element in securing information in high security environments. • Several Protective Security barriers to access information must be penetrated by an external intruder or unauthorized staff member with no “Need to Know”. • Concept of “Security in Depth” 80 79 SECURITY IN DEPTH SECURITY IN DEPTH Protective Security procedures / measures: • The barriers consist of interlocking measures designed to combine to exclude any unauthorized penetration attempt. • Protective Security procedures and measures must be understood by those who will implement and practice them. 81 THREATS TO INFORMATION ASSETS • Staff background checks • Security instructions • Security education programs • Security guards • Access control and surveillance systems • Keys • Safes • Passwords 82 THREATS TO INFORMATION ASSETS Threats that can impact on the Confidentiality, Integrity and Availability of an Information System include the following generic threats: • Accidental Threats 83 • Fire • Programming error • Technical (hardware) failure • Data entry error • Environmental • Failure of power 84 COMPLIANCE OBLIGATIONS THREATS TO INFORMATION ASSETS • Handle all information with care – all information that an employee or contractor accesses must be handled according to policy – official information, personal information (Privacy Act). • Deliberate Threats including: • Denial of Service • Eavesdropping • Information must only be used for the purpose stated by the agency or organization- any other use is misuse. • Malicious code – virus • Malicious code - logic • Malicious destruction of data • Information must be secured appropriately- sound security risk management – Procedures to identify Vital information and information resources. • Malicious destruction of Facilities • Unauthorised access to data • Unauthorised release of data 86 85 COMPLIANCE OBLIGATIONS • Risks must be reduced to an acceptable level. INFORMATION SECURITY PLANS • The Integrity and reliability of information systems which process, store or transmit information - require some level of protection. • If you can’t map your system you can’t secure your data. • Your system is bounded by your data model. • What do you protect ? • Some Government information (official information) is given a security classification where its compromise could cause harm to the nation, the public interest, the Government or other entities or individuals. • The data in the system. • The system is more that the static ICT elements: • Paper • Media – removable • Knowledge – people • Specific security measures must be followed. • Communications – internet, phone, mobile fax etc 87 88 INFORMATION SECURITY PLANS INFORMATION SECURITY PLANS Aim: Provide an effective, integral and available information system and resource by: Development of Information Security Plans requires a good understanding of your data. • Incorporating security into every facet of the architecture, design and operation of the System environment. • Step 1 Understand your information (Data) • Step 2 Understand your Information System. • Establishing a Security Management Strategy. • Step 3 Map your system boundaries Architecture and Policy Plan) • Developing Security Standards. 89 - SAPP (Security 90 INFORMATION SECURITY PLANS INFORMATION SECURITY PLANS • Step 4 Develop an Information Security (IS) Policy. • Implement Security System. • Step 5 Develop an Information Security (IS) Plan. • Implement compliance management system. • Step 6 Develop and implement Risk Management System. • Implement Security Education and Awareness Program Outcome • Step 7 Establish an IS Education Program. Protecting information against unauthorized disclosure, fraud, loss, damage or theft. 91 SECURITY PLANNING 92 SECURITY PLANNING • A security plan must address the following • A security plan • Document describing how an organization addresses its security needs • Periodically reviewed and revised • Creating a security plan • Policy • Current security state • Recommendations and the requirements to meet the security goals • Accountability • Who is responsible for a each security activity • What it should do • Timetable • Who should write the plan • For different security functions • How to acquire support for the plan • Continuing attention for periodic update 93 POLICY 94 INFORMATION SECURITY PROGRAM • Should address • Who should be allowed to access what resources and how should the access be regulated Links in the Security Chain: Management, Operational, and Technical Controls • Should specify • Organizational security goals • Where the responsibility lies (accountability policy); limits of responsibility • Organizational support for security • Legal and ethical aspects? 95 Risk assessment Security planning Security policies and procedures Contingency planning Incident response planning Security awareness and training Physical security Personnel security Certification, accreditation, and security assessments Access control mechanisms Identification & authentication mechanisms (Biometrics, tokens, passwords) Audit mechanisms Encryption mechanisms Firewalls and network security mechanisms Intrusion detection systems Security configuration settings Anti-viral software Smart cards Adversaries attack the weakest link…where is yours? 96 CURRENT SECURITY STATE RECOMMENDATION AND REQUIREMENTS • Can be determined on the basis of risk analysis • It is important to • Indicates • Indicate what requirements are to be imposed in a plan, and over what period • Phase out implementation, and indicate elements of each phase and their time periods • Organizational assets • Security threats to these assets • Controls in place against these threats • The plan • Must be extensible • Must include a procedure for change and growth • Should remain laregely intact through change in the organization 97 98 RESPONSIBILITY FOR IMPLEMENTATION • Identify people/groups implementation responsible TIMETABLE AND CONTINUING ATTENTION for • Timetable • Expensive and complicated controls need gradual adoption • A plan of accountability • Some examples • Training staff on new controls • Personal computer users are responsible for their own machine • Project leaders for data and computations • Database administrators – access and integrity of data in databases • Information officers for creation and use of data, and retention and disposal of data • Personnel staff members – responsible for security involving employees • Continuing attention • Timely review and reevaluation • Update object inventory and list of controls • Review risk analysis to accommodate for parameters that may change 99 100 COMMITMENT TO PLAN PLANNING TEAM • Size • Acceptance of plan • Depends on the complexity of organization and the degree of commitment to security • Organizational behavior studies show optimum size of a working committee: 5 – 9 • Larger committee as oversight body • Committee membership should be from each of the following • Hardware group • Systems/applications programmers • Indicate accountability, • time for accomplishment, • continuing reevaluation, etc. • Education and publicity to help people understand and accept security plan • Management commitment depends on • Encryption, protocols, security in OS and networks require systems programming staff • Data entry personnel • Physical security personnel • Representative users • Needs a concise, well-organized report that includes a plan of implementation and justification of costs 101 • Understanding cause and potential effects of lack of security (Risk analysis) • Cost-effectiveness of security plan 102 • Presentation of the plan ATTRIBUTES OF GOOD POLICIES ORGANIZATIONAL SECURITY POLICIES • Purpose (of the computing facility) • E.g., “protect customers’ confidentiality”, “ensure continual usability” • Protected resources • Purpose • All computers? Networks? All data? Customers’ data? etc. • A policy is written for several different groups • Protection • Beneficiaries • What degree of protection to which resources • Their needs should be captured in the policy • Coverage • Users • Must be comprehensive enough; general enough to apply to new cases • Policy should indicate acceptable use • Durability • Owners • Must grow and adapt well • Policy should express the expectation of owners • Realism • Balance • Protection requirements must be realizable with existing mechanisms • Needs of above groups may conflict • Balance the priorities of all affected communities 104 • Usefulness 103 EXAMPLES • Must be read, understood and followed by all INFORMATION SECURITY POLICY, STANDARDS AND PRACTICES • Four levels S1 o S4 with increasing strength of protection • S1: is not designed to protect any specific resources or any specific level of protection to services • S2: designed to protect regular resources and to provide normal protection against threats • S3: important resources, high protection • Management from all communities of interest must consider policies as the basis for all information security efforts • Policies direct how issues should be addressed and technologies used • Security policies are the least expensive control to execute, but the most difficult to implement • Shaping policy is difficult because: • S4: critical resources, very strong protection 105 • Never conflict with laws • Stand up in court, if challenged • Be properly administered 106 TYPES OF POLICY DEFINITIONS • A policy is Management defines three types of security policy: A plan or course of action, as of a government, political party, or business, intended to influence and determine decisions, actions, and other matters • General or security program policy • Issue-specific security policies • Systems-specific security policies • Policies are organizational laws • Standards, on the other hand, are more detailed statements of what must be done to comply with policy • Practices, procedures and guidelines effectively explain how to comply with policy • For a policy to be effective it must be properly disseminated, read, understood and agreed to by all members of the organization 107 108 SECURITY PROGRAM POLICY POLICIES STANDARDS & PRACTICES • A security program policy (SPP) is also known as a general security policy, IT security policy, or information security policy • Sets the strategic direction, scope, and tone for all security efforts within the organization • An executive-level document, usually drafted by or with, the CIO of the organization and is usually 2 to 10 pages long 110 109 ISSUE-SPECIFIC SECURITY POLICY (ISSP) • As various technologies and processes are implemented, certain guidelines are needed to use them properly • The ISSP: • addresses specific areas of technology • requires frequent updates • contains an issue statement on the organization’s position on an issue • Three approaches: • Create a number of independent ISSP documents • Create a single comprehensive ISSP document • Create a modular ISSP document EXAMPLE ISSP STRUCTURE • Statement of Policy • Authorized Access and Usage of Equipment • Prohibited Usage of Equipment • Systems Management • Violations of Policy • Policy Review and Modification • Limitations of Liability 111 EXAMPLE POLICY 112 SYSTEMS-SPECIFIC POLICY • While issue-specific policies are formalized as written documents, distributed to users, and agreed to in writing, SysSPs are frequently codified as standards and procedures used when configuring or maintaining systems • Systems-specific policies fall into two groups: • Access control lists (ACLs) consists of the access control lists, matrices, and capability tables governing the rights and privileges of a particular user to a particular system • Configuration Rules comprise the specific configuration codes entered into security systems to guide the execution of the system 113 114 INFORMATION SECURITY AUDIT • Conduct of regular Information Security Audit will improve Governance and management of your system. Systems Design • Provide better understanding of information and the system where the information resides. • Improve Governance over all system data. • The key word is UNDERSTANDING. “Managing the unknown will lead to less than optimal data quality.” 115 SYSTEMS DESIGN 116 THE SECSDLC • At this point in the Security SDLC, the analysis phase is complete and the design phase begins – many work products have been created • Designing a plan for security begins by creating or validating a security blueprint • Then use the blueprint to plan the tasks to be accomplished and the order in which to proceed • Setting priorities can follow the recommendations of published sources, or from published standards provided by government agencies, or private consultants 117 118 ISO 17799/BS 7799 INFORMATION SECURITY BLUEPRINTS • One approach is to adapt or adopt a published model or framework for information security • A framework is the basic skeletal structure within which additional detailed planning of the blueprint can be placed as it is developed of refined • Experience teaches us that what works well for one organization may not precisely fit another • One of the most widely referenced and often discussed security models is the Information Technology – Code of Practice for Information Security Management, which was originally published as British Standard 7799 • This Code of Practice was adopted as an international standard by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) as ISO/IEC 17799 in 2000 as a framework for information security 120 119 BS7799-2 ISO 17799 / BS 7799 • Several countries have not adopted 17799 claiming there are fundamental problems: • The global information security community has not defined any justification for a code of practice as identified in the ISO/IEC 17799 • 17799 lacks “the necessary measurement precision of a technical standard” • There is no reason to believe that 17799 is more useful than any other approach currently available. • 17799 is not as complete as other frameworks available • 17799 is perceived to have been hurriedly prepared given the tremendous impact its adoption could have on industry information security controls 121 ISO/IEC 17799 NIST SECURITY MODELS • Organizational Security Policy is needed to provide management direction and support • Objectives: • • • • • • • • • • 122 Operational Security Policy Organizational Security Infrastructure Asset Classification and Control Personnel Security Physical and Environmental Security Communications and Operations Management System Access Control System Development and Maintenance Business Continuity Planning Compliance • Another approach available is described in the many documents available from the Computer Security Resource Center of the National Institute for Standards and Technology (csrc.nist.gov) – Including: • NIST SP 800-12 - The Computer Security Handbook • NIST SP 800-14 - Generally Accepted Principles and Practices for Securing IT Systems • NIST SP 800-18 - The Guide for Developing Security Plans for IT Systems 123 NIST SP 800-14 124 IETF SECURITY ARCHITECTURE • Security Supports the Mission of the Organization • Security is an Integral Element of Sound Mgmt • Security Should Be Cost-Effective • Systems Owners Have Security Responsibilities Outside Their Own Organizations • Security Responsibilities and Accountability Should Be Made Explicit • Security Requires a Comprehensive and Integrated Approach • Security Should Be Periodically Reassessed • While no specific architecture is promoted through the Internet Engineering Task Force, the Security Area Working Group acts as an advisory board for the protocols and areas developed and promoted through the Internet Society • RFC 2196: Site Security Handbook provides an overview of five basic areas of security with detailed discussions on development and implementation • There are chapters on such important topics as security policies, security technical architecture, security services, and security incident handling • Security is Constrained by Societal Factors 125 • 33 Principles enumerated 126 BASELINING AND BEST PRACTICES VISA MODEL • Visa International promotes strong security measures and has security guidelines • Developed two important documents that improve and regulate its information systems • “Security Assessment Process” • “Agreed Upon Procedures” • Using the two documents, a security team can develop a sound strategy for the design of good security architecture • The only down side to this approach is the very specific focus on systems that can or do integrate with VISA’s systems 127 • Baselining and best practices are solid methods for collecting security practices, but can have the drawback of providing less detail than would a complete methodology • It is possible to gain information by baselining and using best practices and thus work backwards to an effective design • The Federal Agency Security Practices Site (fasp.csrc.nist.gov) is designed to provide best practices for public agencies and adapted easily to private organizations 128 PROFESSIONAL MEMBERSHIP HYBRID FRAMEWORK • It may be worth the information security professional’s time and money to join professional societies with information on best practices for its members • The framework proposed here is the result of a detailed analysis of the components of all the documents, standards, and Web-based information described in the previous sections • Many organizations have seminars and classes on best practices for implementing security • It is offered to the student as a balanced introductory blueprint for learning the blueprint development process • Finding information on security design is the easy part, sorting through the collected mass of information, documents, and publications can take a substantial investment in time and human resources 129 130 NIST SP 800-26 NIST SP 800-26 Management Controls • • • • • Operational Controls • • • • • • • • • Risk Management Review of Security Controls Life Cycle Maintenance Authorization of Processing (Certification and Accreditation) System Security Plan Personnel Security Physical Security Production, Input/Output Controls Contingency Planning Hardware and Systems Software Data Integrity Documentation Security Awareness, Training, and Education Incident Response Capability Technical Controls • Identification and Authentication • Logical Access Controls • Audit Trails 131 132 SPHERES OF SECURITY SPHERE OF USE • Generally speaking, the concept of the sphere is to represent the 360 degrees of security necessary to protect information at all times • The first component is the “sphere of use” • Information, at the core of the sphere, is available for access by members of the organization and other computer-based systems: 133 • To gain access to the computer systems, one must either directly access the computer systems or go through a network connection • To gain access to the network, one must either directly access the network or go through an Internet 134 connection SPHERE OF PROTECTION • The “sphere of protection” overlays each of the levels of the “sphere of use” with a layer of security, protecting that layer from direct or indirect use through the next layer • The people must become a layer of security, a human firewall that protects the information from unauthorized access and use • Information security is therefore designed and implemented in three layers Controls • policies • people (education, training and awareness programs) • technology 135 136 CONTROLS • Management Controls cover security processes that are designed by the strategic planners and performed by security administration of the organization • Operational Controls deal with the operational functionality of security in the organization • Operational controls also address personnel security, physical security and the protection of production inputs and outputs • Technical Controls address those tactical and technical issues related to designing and implementing security in the organization 137 Security and the Software Development Lifecycle (SDLC) Online Video follows: 32 minutes 138 Process of Auditing Information Systems Online Video follows: 1 Hour 19 minutes 139 140 COMPONENTS OF AN INFORMATION SYSTEM • Information System (IS) is entire set of software, hardware, data, people, procedures, and networks necessary to use information as a resource in the organization 141 142 SECURING COMPONENTS • Computer can be subject of an attack and/or the object of an attack FIGURE 1-5 – SUBJECT AND OBJECT OF ATTACK • When the subject of an attack, computer is used as an active tool to conduct attack • When the object of an attack, computer is the entity being attacked 143 144 FIGURE 1-6 – BALANCING SECURITY AND ACCESS BALANCING INFORMATION SECURITY AND ACCESS • Impossible to obtain perfect security—it is a process, not an absolute • Security should be considered between protection and availability balance • To achieve balance, level of security must allow reasonable access, yet protect against threats 146 145 APPROACHES TO INFORMATION SECURITY IMPLEMENTATION: BOTTOM-UP APPROACH • Grassroots effort: systems administrators attempt to improve security of their systems • Key advantage: technical expertise of individual administrators • Seldom works, as it lacks a number of critical features: • Participant support 148 • Organizational staying power 147 THE SYSTEMS DEVELOPMENT LIFE CYCLE APPROACHES TO INFORMATION SECURITY IMPLEMENTATION: TOPDOWN APPROACH • Initiated by upper management • Systems development life cycle (SDLC) is methodology and design for implementation of information security within an organization • Issue policy, procedures and processes • Dictate goals and expected outcomes of project • Determine accountability for each required action • The most successful also involve formal development strategy referred to as systems development life cycle 149 • Methodology is formal approach to problem-solving based on structured sequence of procedures • Using a methodology • ensures a rigorous process • avoids missing steps • Goal is creating a comprehensive security posture/program • Traditional SDLC consists of six general phases 150 INVESTIGATION • What problem is the system being developed to solve? • Objectives, constraints and scope of project are specified • Preliminary cost-benefit analysis is developed • At the end, feasibility analysis is performed to assesses economic, technical, and behavioral feasibilities of the process 151 ANALYSIS 152 LOGICAL DESIGN • Consists of assessments of the organization, status of current systems, and capability to support proposed systems • Analysts determine what new system is expected to do and how it will interact with existing systems • Ends with documentation of findings and update of feasibility analysis • Main factor is business need; applications capable of providing needed services are selected • Data support and structures capable of providing the needed inputs are identified • Technologies to implement physical solution are determined • Feasibility analysis performed at the end 153 154 PHYSICAL DESIGN IMPLEMENTATION • Technologies to support the alternatives identified and evaluated in the logical design are selected • Needed software created; components ordered, received, assembled, and tested • Components evaluated on make-or-buy decision • Users trained and documentation created • Feasibility analysis performed; entire solution presented to end-user representatives for approval 155 • Feasibility analysis prepared; users presented with system for performance review and acceptance test 156 MAINTENANCE AND CHANGE • Consists of tasks necessary to support and modify system for remainder of its useful life • Life cycle continues until the process begins again from the investigation phase • When current system can no longer support the organization’s mission, a new project is implemented 157 THE SECURITY SYSTEMS DEVELOPMENT LIFE CYCLE • The same phases used in traditional SDLC may be adapted to support specialized implementation of an IS project • Identification of specific threats and creating controls to counter them • SecSDLC is a coherent program rather than a series of random, seemingly unconnected actions 158 INVESTIGATION ANALYSIS • Identifies process, outcomes, goals, and constraints of the project • Documents from investigation phase are studied • Begins with enterprise information security policy • Analyzes existing security policies or programs, along with documented current threats and associated controls • Organizational performed • Includes analysis of relevant legal issues that could impact design of the security solution feasibility analysis is • The risk management task begins 159 LOGICAL DESIGN • Creates and develops information security blueprints 160 PHYSICAL DESIGN for • Needed security technology is evaluated, alternatives generated, and final design selected • Incident response actions planned: • Continuity planning • Incident response • Disaster recovery • Feasibility analysis to determine whether project should continue or be outsourced 161 • At end of phase, feasibility study determines readiness of organization for project 162 IMPLEMENTATION MAINTENANCE AND CHANGE tested, • Perhaps the most important phase, given the everchanging threat environment • Personnel issues evaluated; specific training and education programs conducted • Often, reparation and restoration of information is a constant duel with an unseen adversary • Entire tested package is presented management for final approval • Information security profile of an organization requires constant adaptation as new threats emerge and old threats evolve • Security solutions are acquired, implemented, and tested again to 163 SECURITY PROFESSIONALS AND THE ORGANIZATION 164 SENIOR MANAGEMENT • Chief Information Officer (CIO) • Wide range of professionals required to support a diverse information security program • Senior management is key component; also, additional administrative support and technical expertise required to implement details of IS program • Senior technology officer • Primarily responsible for advising senior executives on strategic planning • Chief Information Security Officer (CISO) • Primarily responsible for assessment, management, and implementation of IS in the organization • Usually reports directly to the CIO 166 165 INFORMATION SECURITY PROJECT TEAM DATA OWNERSHIP • A number of individuals who are experienced in one or more facets of technical and nontechnical areas: • Champion • Team leader • Security policy developers • Risk assessment specialists • Data Custodian: responsible for storage, maintenance, and protection of information • Data Users: end users who work with information to perform their daily jobs supporting the mission of the organization • Security professionals • Systems administrators • End users • Data Owner: responsible for the security and use of a particular set of information 168 167 COMMUNITIES OF INTEREST • Group of individuals united by interest/values in an organization • Information Security Professionals Management • Information Technology Professionals KEY TERMS similar Management and and • Organizational Management and Professionals 169 • Security Blueprint • Access • Asset • Security Model • Attack • Security Posture or • Control, Safeguard or Security Profile Countermeasure • Subject • Exploit • Exposure • Threats • Hacking • Threat Agent • Object • Vulnerability • Risk 170 SUMMARY SUMMARY • Information security is a “well-informed sense of assurance that the information risks and controls are in balance.” • Computer security began immediately after first mainframes were developed • Successful organizations have multiple layers of security in place: physical, personal, operations, communications, network, and information. 171 Any Questions? 173 • Security should be considered a balance between protection and availability • Information security must be managed similar to any major system implemented in an organization using a methodology like SecSDLC 172 Student Assessment Information The process you will be following is known as competency-based assessment. This means that evidence of your current skills and knowledge will be measured against national and international standards of best practice, not against the learning you have undertaken either recently or in the past. (How well can you do the job?) Some of the assessment will be concerned with how you apply the skills and knowledge in your workplace, and some in the training room. The assessment tasks utilized in this training have been designed to enable you to demonstrate the required skills and knowledge and produce the critical evidence required so you can successfully demonstrate competency at the required standard. What happens if your result is ‘Not Yet Competent’ for one or more assessment tasks? The assessment process is designed to answer the question “has the participant satisfactorily demonstrated competence yet?” If the answer is “Not yet”, then we work with you to see how we can get there. In the case that one or more of your assessments has been marked ‘NYC’, your Trainer will provide you with the necessary feedback and guidance, in order for you to resubmit/redo your assessment task(s). What if you disagree on the assessment outcome? You can appeal against a decision made in regards to an assessment of your competency. An appeal should only be made if you have been assessed as ‘Not Yet Competent’ against specific competency standards and you feel you have sufficient grounds to believe that you are entitled to be assessed as competent. You must be able to adequately demonstrate that you have the skills and experience to be able to meet the requirements of the unit you are appealing against the assessment of. You can request a form to make an appeal and submit it to your Trainer, the Course Coordinator, or an Administration Officer. The RTO will examine the appeal and you will be advised of the outcome within 14 days. Any additional information you wish to provide may be attached to the form. What if I believe I am already competent before training? If you believe you already have the knowledge and skills to be able to demonstrate competence in this unit, speak with your Trainer, as you may be able to apply for Recognition of Prior Learning (RPL). Credit Transfer Credit transfer is recognition for study you have already completed. To receive Credit Transfer, you must be enrolled in the relevant program. Credit Transfer can be granted if you provide the RTO with certified copies of your qualifications, a Statement of Attainment or a Statement of Results along with Credit Transfer Application Form. (For further information please visit Credit Transfer Policy) 243 | P a g e LEARNING OUTCOMES The following critical aspects must be assessed as part of this unit: 1. Interact with customers, collect the necessary information and match customers' needs to company products or service 2. Sell products and services including matching customers' requirements to company products and services and finalise and record the sale LEARNING ACTIVITIES Class will involve a range of lecture based training, activities, written task, case study and questioning. STUDENT FEEDBACK We welcome your feedback as one way to keep improving this unit. Later this semester, you will be encouraged to give unit feedback through completing the Quality of Teaching and Learning Survey LEARNING RESOURCES Other Learning Resources available to students include: Candidate Resource & Assessment: ICTNWK510 Develop, implement and evaluate system and application security Presentation handout PPT Presentation TEXTBOOKS You do not have to purchase the following textbooks but you may like to refer to them: Unit Code(s) Unit Title ICTNWK510 Develop, implement and evaluate system and application security Reference Book/ Trainer & Learner Resource 7BCole, Kris. 2010 Management Theory and Practice Network Security Essentials: Applications and Standards, 4th Edition; William Stallings 244 | P a g e Additional Reference Texts A Developers Guide to Network Security; Richard Conway, Julian Cordingley Firewalls and Network Security; Michael E. Whitman, Herbert Mattford, Richard Austin, Greg Holden Network Security: The Complete Reference 1st Edition; Roberta Bragg, Keith Strassberg, Mark Rhodes-Ousley Network Security Bible 2nd Edition; Eric Cole Cryptography and Quantum Computing: Securing Business Information; Bradley Tice 7BCole, Kris. 2010 Management Theory and Practice Network Security Essentials: Applications and Standards, 4th Edition; William Stallings A Developers Guide to Network Security; Richard Conway, Julian Cordingley Firewalls and Network Security; Michael E. Whitman, Herbert Mattford, Richard Austin, Greg Holden Network Security: The Complete Reference 1st Edition; Roberta Bragg, Keith Strassberg, Mark Rhodes-Ousley Network Security Bible 2nd Edition; Eric Cole Cryptography and Quantum Computing: Securing Business Information; Bradley Tice ASSESSMENT DETAILS Assessment Summary The assessment for this unit consists of the following items. Knowledge Assessment 245 | P a g e Task 1: Systems Analysis and Design Task 2: Develop, implement and evaluate system and application security Formative Activities In addition to the three assessment tasks, students will be required to complete activities as outlined by their trainer/assessor – these will be taken from class resources, Enhance Your Future Learner Guides. Referencing Style Students should use the referencing style outlined by the Trainer when preparing assignments. More information can be sought from your Course Trainer. Guidelines for Submission 1. An Assignment Cover Sheet (or cover page) must accompany all assignments at front to confirm it is your own assessment/ work. 2. All assignments must be within the specified timeframe (please refer to Due Date). Assignment Marking Students should allow 14 days’ turnaround for written assignments. Plagiarism Monitoring Students should use the referencing style outlined by when preparing assignments. More information can be sought from your Trainer. Marking Guide C Competent: for students who have achieved all of the learning outcomes specified for that unit/module to the specified standard. NYC Not Yet Competent: for students who are required to re-enrol in a unit/ module in their endeavour to achieve competence S Satisfactory: has achieved all the work requirements 246 | P a g e NS Not Satisfactory: has not achieved all the work requirements Every student at Danford College can expect to have “timely fair and constructive assessment of work.” Assessment tasks must be marked in such a way that the result reflects how well a student achieved the learning outcomes and in accordance with the assessment criteria. In addition to the final result, returned assignments must be accompanied by feedback that clearly explains how the marking result/s was derived (summative), as well as how the student can improve (formative). Refer to observation checklist below and/or consult your trainer/assessor for marking criteria for this unit. STUDENTS’ RIGHTS AND RESPONSIBILITIES It is the responsibility of every student to be aware of all relevant legislation, policies and procedures relating to their rights and responsibilities as a student. These include: The Student Code of Conduct The College’s policy and statements on plagiarism Copyright principles and responsibilities The College’s policies on appropriate use of software and computer facilities Students’ responsibility to attend, update personal details and enrolment Course Progress Policy and Attendance Deadlines, appeals, and grievance resolution Student feedback Other policies and procedures. Electronic communication with students International Students Please also refer to ESOS framework for further details https://internationaleducation.gov.au/Regulatory-Information/Education-Services-for-OverseasStudents-ESOS-Legislative-Framework/ESOS-Act ADDITIONAL INFORMATION Contacts: If you have a query relating to administrative matters such as obtaining assessment results, please contact your Course co-ordinator. 247 | P a g e Deferrals/Suspensions/Cancellations Danford College will only allow deferrals/student requested suspensions under exceptional compassionate circumstances. Once a student has commenced studies, students are not allowed to take leave unless there are compelling and compassionate reasons. Please refer to the College’s Deferment, Suspension and Cancellation Policy available in the Student Handbook and at Student Administration. This policy has been explained to you at Orientation. Course Progress Policy You are expected to attend all classes and complete your units of study satisfactorily, within your term. Your Course Trainer will make a report to the Course co-ordinator if there are any concerns about your progress. The Course Progress Policy is available to you in the Student Handbook and at Student Administration or on college website www.danford.edu.au. Assessment Conditions Gather evidence to demonstrate consistent performance in conditions that are safe and replicate the workplace. Noise levels, production flow, interruptions and time variances must be typical of those experienced in the network industry, and include access to: ICT business specifications information on the security environment, including laws and legislation, existing organisational security policies, organisational expertise and knowledge possible security environment, which also includes the threats to security that are, or are held to be, present in the environment risk analysis tools and methodologies ICT security assurance specifications application and system scenarios. Assessors must satisfy SRTO2015/AQF assessor requirements. 248 | P a g e Lesson/Session Plan For face-to-face classroom based delivery as per timetable. Delivery Day 1 2 Delivery Topics Introduction to ICTNWK510 Develop, implement and evaluate system and application security and Assessment Requirements Overview (Page 5) Identify enterprise ICT system or application security policies (Page 10) Identify security requirements for the ICT system or application (Page 38) Write an ICT system or application security plan according to the enterprise and ICT system or application security policies (Page 58) Identify standards against which to engineer the ICT system or application (Page 95) AS/NZS ISO/IEC 38500:2010 ISO/IEC 38500:2008 Australian/New Zealand Standard™ Corporate governance of information technology 3 Identify criteria for performing risk based audits against the ICT system or application (Page 102) Develop processes and procedures to mitigate the introduction of vulnerabilities during the engineering process (Page 129) 4 Integrate applicable information security requirements, controls, processes, and procedures into ICT system and application design specifications according to established requirements (Page 158) Execute enterprise and ICT system or application security policies (Page 169) Apply and verify compliance with identified standards against which to engineer the ICT system or application (Page 177) Activities to be undertaken Work through corresponding sections of Learner Materials and Assessment Tasks Activity 1 (Page 17) Activity 2 (Page 49) Commence Written Questions PowerPoint Presentation – Slides 1 68 Work through corresponding sections of Learner Materials and Assessment Tasks Activity 3 (Page 90) Activity 4 (Page 102) Commence Task 1 – Systems Analysis and Design Commence Task 2 – Develop, implement and evaluate system and application security PowerPoint Presentation – Slides 69 104 Work through corresponding sections of Learner Materials and Assessment Tasks Activity 5 (Page 115) Activity 6 (Page 146) Work through corresponding sections of Learner Materials and Assessment Tasks Activity 7 (Page 174) Activity 8 (Page 181) PowerPoint Presentation – Slides 105-113 249 | P a g e Delivery Day 5 6 7 8 9 Delivery Topics Perform processes and procedures to mitigate the introduction of vulnerabilities during the engineering process (Page 184) Perform secure configuration management practices (Page 188) Validate that the engineered ICT system and application security controls meet the specified requirements (Page 202) Re-engineer security controls to mitigate vulnerabilities identified during the operations phase (Page 204) Ensure integration of information security practices throughout the SDLC process (Page 204) Document ICT system or application security controls addressed within the system (Page 205) Practise secure coding (Page 206) Review new and existing risk management technologies to achieve an optimal enterprise risk posture (Page 213) Review new and existing ICT security technologies to support secure engineering across the SDLC phases (Page 214) Continually assess effectiveness of the information system controls based on risk management practices and procedures (Page 215) Assess and evaluate system compliance with corporate policies and architectures (Page 225) Assess system maturation and readiness for promotion to the production stage (Page 228) Collect lessons learned from integration of information security into the SDLC and use to identify improvement actions (Page 231) Collect, analyse and report performance measures (Page 240) Activities to be undertaken Work through corresponding sections of Learner Materials and Assessment Tasks Activity 9 (Page 198) PowerPoint Presentation – Slides 114 - 132 Work through corresponding sections of Learner Materials and Assessment Tasks PowerPoint Presentation – Slides 133 - 134 Work through corresponding sections of Learner Materials and Assessment Tasks Activity 10 (Page 210) PowerPoint Presentation – Slides 135 - 136 Work through corresponding sections of Learner Materials and Assessment Tasks PowerPoint Presentation – Slides 137 - 171 Work through corresponding sections of Learner Materials and Assessment Tasks Activity 11 (Page 238) Activity 12 (Page 241) Complete Written Questions 250 | P a g e Delivery Day 10 Delivery Topics ASSESSMENT Activities to be undertaken Complete Task 1 – Systems Analysis and Design Complete Task 2 – Develop, implement and evaluate system and application security 251 | P a g e Knowledge Assessment (Written Tasks) 1. What is an Enterprise Security Policy? 2. What is an Information Systems Audit? 252 | P a g e 3. How is an Information Systems Audit Conducted? 4. Don’s company is using the waterfall model of software development. Which one of the following transitions is not acceptable under this model? 253 | P a g e (a) Code & Debug -> Testing (b) System Requirements -> Software Requirements (c) Testing -> Operations & Maintenance (d) Software Requirements -> Testing 5. What are the Testing Levels? (a) Unit Testing (b) Integration Testing (c) System Testing and Acceptance Testing. (d) All the above 6. Requirement and Analysis, Design, Development or Coding, Testing and Maintenance is called as Software Development Life Cycle (SDLC ) (a) True (b) False 7. Configuration Management Plan describes the Configuration Management procedures and structures to be used. (a) True (b) False 8. A metric used to measure the characteristic of documentation and code called as (a) Process metric (b) Product Metric (c) Test metrics 9. Integration of security processes with the SDLC – Complete the table below to outline the security processes related to the SDLC Phases: SDLC Phases Requirements Security Processes Design Coding and Unit Testing Integration Testing System Testing 254 | P a g e Implementation Support 10. A security evaluation report and an accreditation statement are produced in which of the following phases of the system development life cycle? 255 | P a g e Task 1 – Systems Analysis and Design Answer All Questions: True/False Indicate whether the statement is true or false. ____ 1. Systems analysis and design focuses on understanding the business problem and outlining the approach to solve it. ____ 2. When choosing between possible solutions to a business problem, the best solution is the one with the fewest risks and the most benefits. ____ 3. A systems analyst needs to understand people and the way they work. ____ 4. A systems analyst needs to be an expert in all types of technology. ____ 5. Analysts must upgrade their knowledge and skills continually. ____ 6. Technology alone increases productivity and profits. ____ 7. Systems analysis means understanding and specifying in detail what the information system should accomplish. ____ 8. The systems analyst's work is described as problem solving for an organization. ____ 9. A system is a collection of interrelated components that function together to achieve some outcome. ____ 10. The first four major phases of the predictive systems development life cycle (SDLC) are the planning phase, the analysis phase, the design phase, and the prototyping phase. ____ 11. The primary objective of analysis activities is to understand the business needs and processing requirements of the new system. ____ 12. The support phase includes maintaining and enhancing the system. ____ 13. The first activity in the project planning phase is to develop the project schedule. ____ 14. Feasibility analysis investigates economic, organizational, technical, resource, and schedule feasibility. ____ 15. The support phase is the shortest and least expensive phase of the system development life cycle (SDLC). ____ 16. A tool is a software support that helps create models or other components required in the project. 256 | P a g e ____ 17. During the design phase, analysts begin to define a computer-system solution. ____ 18. Implementation is the actual construction, testing, and installation of a functioning information system. ____ 19. The most important activity of project planning is to define precisely the business problem and the scope of the required solution. ____ 20. A predictive SDLC has a high technical risk. ____ 21. A project cannot have both predictive and adaptive elements. ____ 22. The spiral model is generally considered to be the first adaptive approach to system development. ____ 23. A methodology contains guidelines to follow for completing every activity in the systems development life cycle. ____ 24. A project management software application is an example of a tool. ____ 25. Structured programming and top-down programming are identical concepts. ____ 26. technique. The data flow diagram is used with the structured analysis system development ____ 27. approach. The class diagram is used with the Information Engineering system development ____ A model is a representation of an important aspect of the real world. 28. Multiple Choice Identify the choice that best completes the statement or answers the question. ____ 29. The process of understanding and specifying in detail what the information system should accomplish is called systems ____. a. design c. analysis b. specification d. administration ____ 30. Systems ____ means specifying in detail how the many components of the information system should be physically implemented. a. design c. analysis b. specification d. administration ____ 31. The most important role of a systems analyst in business is ____. 257 | P a g e a. b. c. d. technical understanding of information systems problem solving knowing what data needs to be stored and used special programming skills ____ 32. ____ refers to the division of a system into processes or subsystems. a. System design c. Programming b. Data management d. Functional decomposition ____ 33. An automation boundary is best described as the separation between the ____. a. system and its environment b. automated part of a system and the manual part of a system c. manual part of a system and its environment d. automated part of a system and its environment ____ 34. Changes in software development, technology, and business practices have created many new career opportunities for analysts, including ____. a. Sales and support of ERP software c. Web development b. Auditing, compliance, and security d. All of the above ____ 35. A technique that seeks to alter the nature of the work done in a business function, with the objective of radically improving performance, is called ____. a. business process reengineering c. information systems strategic planning b. strategic planning d. enterprise resource planning (ERP) ____ 36. A description of the integrated information systems needed by the organization to carry out its business functions is called ____. a. business process re-engineering c. technology architecture plan b. application architecture plan d. enterprise resource planning (ERP) ____ 37. A description of the hardware, software, and communications networks required to implement planned information systems is called ____. a. information systems strategic planning c. technology architecture plan b. applications architecture planning d. enterprise resource planning (ERP) ____ 38. Rocky Mountain Outfitters would like to further distribute business applications across multiple locations and computer systems, reserving the data center for Web server, database, and telecommunications functions. This is an example of ____. a. applications architecture planning c. technology architecture planning b. enterprise resource planning (ERP) d. strategic planning 258 | P a g e ____ 39. Which of the following is an example of a technique used to complete specific system development activities? a. project planning b. integrated development environment (IDE) c. application service provider (ASP) d. supply chain management (SCM) ____ 40. Which of the following is the analyst’s approach to problem solving? a. Verify that the benefits of solving the problem outweigh the costs, then research and understand the problem. b. Develop a set of possible solutions, then verify that the benefits of solving the problem outweigh the costs. c. Verify that the benefits of solving the problem outweigh the costs, then define the requirements for solving the problem. d. Implement the solution, then define the details of the chosen solution. ____ 41. The last step of the analyst's approach to problem solving is ____. a. Decide which solution is best, and make a recommendation b. Monitor to make sure that you obtain the desired results c. Verify that the benefits of solving the problem outweigh the costs d. Implement the solution ____ 42. A knowledge management system ____. a. indexes all the knowledge contained within an organization b. supports the storage of and access to documents within an organization c. is another term for a library system d. requires a very large amount of online storage space ____ 43. Skills in a nontechnical area such as interviewing and team management are called ____. a. inherent skills c. hard skills b. technical skills d. soft skills ____ 44. An example of a project phase in a predictive project is ____. a. gathering information about the user's needs b. performing a project cost/benefit analysis c. planning the project d. drawing the system interface 259 | P a g e ____ 45. The primary objective of the analysis phase is to ____. a. analyze the capabilities and structure of the previous system b. prioritize the alternatives for a new system c. determine the basic structure and approach for the new system d. understand and document the users' needs and requirements ____ 46. The problem domain is the part of systems development that refers to the ____. a. problems associated with the computing environment b. area of the user's business for which a system is being developed c. problems of the organization of the company d. area of the industry that results in more intense competition ____ 47. That portion of the new information system that satisfies the user's business needs in the problem domain is referred to as the ____. a. system procedure c. network b. application d. user interface ____ 48. The ____ phase begins only after the new system has been installed and put into production, and it lasts throughout the productive life of the system. a. analysis c. implementation b. design d. support ____ 49. Users are typically more involved in the project during which two phases? a. Analysis and design c. Design and implementation b. Planning and analysis d. Analysis and implementation ____ 50. The first official activity of the project team as it initiates the project planning phase is to ____. a. define the business problem c. develop a cost/benefit analysis b. staff the project team d. write a project proposal ____ 51. The term “____” describes a planned undertaking that produces a new information system. a. systems development project c. systems development life cycle (SDLC) b. phase d. design phase ____ 52. Most new information systems must communicate with other, existing systems, so the design of the method and details of these communication links must be precisely defined. These are called ____. a. models c. help desks 260 | P a g e b. system interfaces d. design interfaces ____ 53. The term “____” means that work activities are done once, then again, and yet again. a. eXtreme programming (XP) c. agile modeling b. iteration d. Unified Process (UP) ____ 54. The term ____ refers to an approach that completes parts of a system in one or more iterations and puts them into operation for users. a. incremental development c. Unified Process (UP) b. information engineering (IE) d. structured design ____ 55. A(n) ____ in system development is a collection of guidelines that help an analyst complete a system development activity or task. a. iteration c. technique b. model d. tool ____ is one that has one beginning and one ending. a. iterative c. incremental b. structured d. object-oriented 56. A(n) ____ program ____ 57. ____ programming divides more complex programs into a hierarchy of program modules. a. Incremental c. Object-oriented b. Iterative d. Top-down ____ 58. The key graphical model of the systems requirements used with structured analysis is the ____. a. flowchart b. data flow diagram (DFD) c. class diagram d. project evaluation and review technique (PERT) chart ____ 59. A(n) ____ is a thing in the computer system that is capable of responding to messages. a. entity-relationship diagram (ERD) c. tool b. model d. object 261 | P a g e ____ 60. The ____ is a critical component of any new system. a. project management application c. reverse engineering tool b. user interface d. code generator tool ____ 61. The objective of the ____ phase is to keep the system running productively during the years following its initial installation. a. support c. planning b. design d. analysis ____ 62. The ____ technique was developed to provide some guidelines for deciding what the set of programs should be, what each program should accomplish, and how the program should be organized into a hierarchy. a. Extreme programming (XP) c. object-oriented b. structured design d. structure chart ____ 63. A key concept in the ____ model approach is the focus on risk. a. spiral c. risk b. Extreme programming (XP) d. agile ____ 64. A(n) _____ approach to the SDLC is used when the exact requirements of a system or needs of users are not well understood. a. predictive c. incremental b. persistent d. adaptive ____ 65. The _____ approach is an SDLC approach that assumes the various phases of a project can be completed entirely sequentially. a. waterfall c. prototype b. artifact d. spiral model ____ 66. Visual modelling tools usually contain a database of information about the models and the project, which is called a(n) ____. a. knowledge base c. library b. information base d. repository ____ 67. One popular visual modelling tool is ____. a. Firefox c. Visio b. PowerPoint d. Photoshop 262 | P a g e Task 2 – Develop, implement and evaluate system and application security This assessment task requires the development of a configuration script for a Cisco networking device to meet the requirements of the network specification within the networking environment. Your task is to handle system and application security from the development phase through implementation to evaluation. Relevant standards to scripting in IOS must be applied to all coded and applied scripts and security best practice must be applied. During the development and implementation, vulnerabilities must be mitigated including: buffer overflows errors in application or system poor design trapdoors undefined or undocumented code undefined variables untested code. You should access and take into account: IT business specifications information on the security environment, including laws and legislation, existing organisational security policies, organisational expertise and knowledge possible security environment, which also includes the threats to security that are, or are held to be, present in the environment risk analysis tools and methodologies IT security assurance specifications application and system scenarios Complete and submit the following: Project overview Copy of the applied and reviewed security policies Checklist of Security-related Tasks & Subtasks 263 | P a g e Checklist of Security-related Tasks & Subtasks 264 | P a g e 265 | P a g e 266 | P a g e 267 | P a g e 268 | P a g e 269 | P a g e 270 | P a g e 271 | P a g e ICT50418 DIPLOMA OF INFORMATION TECHNOLOGY NETWORKING College Copy Unit Code and Title: ICTNWK510 Develop, implement and evaluate system and application security Assessment task Due Dates Assessment 1 Due Date: Assessment 2 Due Date: Assessment 3 Due Date: I Student ID acknowledge receiving the Student Assessment Information Pack, which contains: o o o o o o o o Assessment Due Date Sheet Time table /Training Plan Lesson Plan Student Assessment Information Guide Assessment Cover Sheets Feedback form Student Resource Internet Access for online Business Environment Simulation with Login Key or access to college simulated business documents on internal intranet. Student Signature: Date : 272 | P a g e ICT50418 DIPLOMA OF INFORMATION TECHNOLOGY NETWORKING Student Copy Unit Code and Title: ICTNWK510 Develop, implement and evaluate system and application security Assessment task Due Dates Assessment 1 Due Date: Assessment 2 Due Date: Assessment 3 Due Date: I Student ID acknowledge receiving the Student Assessment Information Pack, which contains: o o o o o o o o Assessment Due Date Sheet Time table / Training Plan Lesson Plan Student Assessment Information Guide Assessment Cover Sheets Feedback form Student Resource Internet Access for online Business Environment Simulation with Login Key or access to college simulated business documents on internal intranet. Student Signature: Date : 273 | P a g e ASSESSMENT SUMMARY / COVER SHEET This form is to be completed by the assessor and used a final record of student competency. All student submissions including any associated checklists (outlined below) are to be attached to this cover sheet before placing on the students file. Student results are not to be entered onto the Student Database unless all relevant paperwork is completed and attached to this form. Student Name: Student ID No: Final Completion Date: Unit Code: ICTNWK510 Unit Title: Develop, implement and evaluate system and application security Assessors Name: Unit Outcome C NYC Result: S = Satisfactory, NYS = Not Yet Satisfactory, NA = Not Assessed Knowledge Assessment - Questions and Answers Task 1 S | NYS | NA Task 2 S | NYS | NA S | NYS | NA Is the Learner ready for assessment? Yes No Has the assessment process been explained? Yes No Yes No Yes No Yes No Does the Learner understand which evidence is to be collected and how? Have the Learner’s rights and the appeal system been fully explained? Have you discussed any special needs to be considered during assessment? I agree to undertake assessment in the knowledge that information gathered will only be used for professional development purposes and can only be accessed by my manager and the RTO: Learner Signature: I have received, discussed and accepted my result as mentioned above for this unit assessment and I am aware about my rights to appeal. Date: Assessor Signature: I declare that I have conducted a fair, valid, reliable and flexible assessment with this student, and I have provided appropriate feedback. Date: 274 | P a g e ASSESSMENT COVER SHEET Unit ICTNWK510 Develop, implement and evaluate system and application security Course ICT50418 DIPLOMA OF INFORMATION TECHNOLOGY NETWORKING Student Name: Student ID: Group: Date Title of Assignment: Knowledge Assessment - Questions and Answers Assessor Name: This cover sheet must be attached to your assignment. Declaration: 1. I am aware that penalties exist for plagiarism and unauthorized collusion with other students. 2. I am aware of the requirements set by my educator with regards to the presentation of documents and assignments. 3. I have retained a copy of my assignment. Student Signature:___________________________ Date:________________________________________ 275 | P a g e QUESTION & ANSWER CHECKLIST S NYS Learner’s name: Assessor’s name: Question Correct () 1 2 3 4 5 6 7 8 9 10 Feedback to Learner: Assessor’s Signature: Date: 276 | P a g e ASSESSMENT COVER SHEET Unit ICTNWK510 Develop, implement and evaluate system and application security Course ICT50418 DIPLOMA OF INFORMATION TECHNOLOGY NETWORKING Student Name: Student ID: Group: Date Title of Assignment: Task 1 Assessor Name: This cover sheet must be attached to your assignment. Declaration: 1. I am aware that penalties exist for plagiarism and unauthorized collusion with other students. 2. I am aware of the requirements set by my educator with regards to the presentation of documents and assignments. 3. I have retained a copy of my assignment. Student Signature:___________________________ Date:________________________________________ 277 | P a g e TASK 1 CHECKLIST S NYS Learner’s name: Assessor’s name: Observation Criteria S NS Identified enterprise ICT system or application security policies Identified security requirements for the ICT system or application Wrote an ICT system or application security plan according to the enterprise and ICT system or application security policies Identified standards against which to engineer the ICT system or application Identified criteria for performing risk based audits against the ICT system or application Developed processes and procedures to mitigate the introduction of vulnerabilities during the engineering process Integrated applicable information security requirements, controls, processes, and procedures into ICT system and application design specifications according to established requirements Executed enterprise and ICT system or application security policies Applied and verified compliance with identified standards against which to engineer the ICT system or application Performed processes and procedures to mitigate the introduction of vulnerabilities during the engineering process Performed secure configuration management practices Validated that the engineered ICT system and application security controls meet the specified requirements Re-engineered security controls to mitigate vulnerabilities identified during the operations phase Ensured integration of information security practices throughout the SDLC process Documented ICT system or application security controls addressed within the system Practised secure coding Reviewed new and existing risk management technologies to achieve an optimal enterprise risk posture Reviewed new and existing ICT security technologies to support secure engineering across the SDLC phases 278 | P a g e Continually assessed effectiveness of the information system controls based on risk management practices and procedures Assessed and evaluated system compliance with corporate policies and architectures Assessed system maturation and readiness for promotion to the production stage Collected lessons learned from integration of information security into the SDLC and use to identify improvement actions Collected, analyse and report performance measures Feedback to Learner: Assessor’s Signature: Date: 279 | P a g e ASSESSMENT COVER SHEET Unit ICTNWK510 Develop, implement and evaluate system and application security Course ICT50418 DIPLOMA OF INFORMATION TECHNOLOGY NETWORKING Student Name: Student ID: Group: Date Title of Assignment: Task 2 Assessor Name: This cover sheet must be attached to your assignment. Declaration: 1. I am aware that penalties exist for plagiarism and unauthorized collusion with other students. 2. I am aware of the requirements set by my educator with regards to the presentation of documents and assignments. 3. I have retained a copy of my assignment. Student Signature:___________________________ Date:________________________________________ 280 | P a g e TASK 2 CHECKLIST S NYS Learner’s name: Assessor’s name: Observation Criteria S NS Identified enterprise ICT system or application security policies Identified security requirements for the ICT system or application Wrote an ICT system or application security plan according to the enterprise and ICT system or application security policies Identified standards against which to engineer the ICT system or application Identified criteria for performing risk based audits against the ICT system or application Developed processes and procedures to mitigate the introduction of vulnerabilities during the engineering process Integrated applicable information security requirements, controls, processes, and procedures into ICT system and application design specifications according to established requirements Executed enterprise and ICT system or application security policies Applied and verified compliance with identified standards against which to engineer the ICT system or application Performed processes and procedures to mitigate the introduction of vulnerabilities during the engineering process Performed secure configuration management practices Validated that the engineered ICT system and application security controls meet the specified requirements Re-engineered security controls to mitigate vulnerabilities identified during the operations phase Ensured integration of information security practices throughout the SDLC process Documented ICT system or application security controls addressed within the system Practised secure coding Reviewed new and existing risk management technologies to achieve an optimal enterprise risk posture Reviewed new and existing ICT security technologies to support secure engineering across the SDLC phases 281 | P a g e Continually assessed effectiveness of the information system controls based on risk management practices and procedures Assessed and evaluated system compliance with corporate policies and architectures Assessed system maturation and readiness for promotion to the production stage Collected lessons learned from integration of information security into the SDLC and use to identify improvement actions Collected, analyse and report performance measures Feedback to Learner: Assessor’s Signature: Date: 282 | P a g e Student Feedback Form Unit ICTNWK510 Develop, implement and evaluate system and application security Student Name: Date Assessor Name: Please provide us some feedback on your assessment process. Information provided on this form is used for evaluation of our assessment systems and processes. This information is confidential and is not released to any external parties without your written consent. There is no need to sign your name as your feedback is confidential. Strongly Strongly Agree Disagree Agree I received information about the assessment requirements prior to undertaking the tasks 1 2 3 4 5 The assessment instructions were clear and easy to understand 1 2 3 4 5 I understood the purpose of the assessment 1 2 3 4 5 The assessment meet your expectation 1 2 3 4 5 My Assessor was organised and well prepared 1 2 3 4 5 The assessment was Fair, Valid, Flexible and Reliable 1 2 3 4 5 My Assessor's conduct was professional 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5 The assessment was an accurate reflection of the unit requirements I was comfortable with the outcome of the assessment I received feedback about assessments I completed The pace of this unit was: Too Slow Great Pace Too Fast Comments: 283 | P a g e