Information Systems Management

Information Systems Management
Dr.MohitBansal Profile Pic
Dr.MohitBansal,Canada,Teacher
Published Date:26-10-2017
Your Website URL(Optional)
Comment
Information Systems Management Introduction Today’s world is complex. Organizational environment is becoming increasingly complicated with the integration of various technologies to provide better business delivery. While one’s need of effective and efficient delivery is fulfilled through the means of new technologies, such as internet, video, audio, business presentations, and business meetings, interplaying with each other, the other need requires more focus and strengthening, that is, information security. Businesses have to protect the confidentiality, and the integrity of business information while making their systems available for continued business. A few minutes of down time of an e-commerce business site can lead to a significant amount of missed business or switching over of the business to a competitive supplier. A breach of confidentiality or integrity can lead to reputation loss, huge penalties, or significant revenue loss. To ensure information security, we need to act proactively. When pro-activeness does not stop the breaches, we need to react effectively and efficiently and when breaches cannot be avoided we need to recover the businesses as fast as possible to provide continued services to the customers. Risk Management when applied in the right spirit, with the deployment of the right methodology, with the involvement of the right people, with the application of the right thinking, and with the execution of the actions effectively, can provide a reasonably good proactive approach to ensure that there is a high chance of avoiding information security breaches or incidents. In spite of being proactive, we cannot be assured that the security breaches cannot happen, as this evolving world provides a lot of opportunities and ways to breach the system. Incident response provides a reactive method to ensure that the breaches are handled, contained, and recovered from effectively. In spite of effective risk management and incident response systems in place, you cannot still be assured of continuity of business or speedy recovery when the organization is affected by severe security breaches or disasters. Hence the need for effective disaster recovery and business continuity systems to be put in place which is again a proactive as well as a reactive system to ensure that the business can still continue in spite of disasters or severe security incidents when there is high probability of speedy recovery. Most of the businesses may go out of business or may lose a significant number of customers if they are not able to recover within a reasonable time frame. Similarly, some of the businesses cannot sustain a short period of lack of availability of systems as some of their business is highly critical and needs to be continued at any cost even at a reduced level of activity / volume. An effective risk management approach supported by an effective and efficient incident response, supported by an effective and efficient disaster recovery and business continuity system can ensure that the businesses are able to sustain and provide continued services to their clients in spite of serious security breaches or disasters. Unfortunately, there are hundreds of theories proposed by the experts and varied practices employed by various organizations with respect to risk management, incident response, disaster recovery, and business continuity. The definition of each of these words, from incident to disaster to recovery to continuity varies from theory to theory. In order not to confuse our readers with too many theories and too many definitions we are providing here simple definitions in simple terms with respect to each of these as well as a simple and practical way of handling each of these, which in our view is suitable to most of the organizations in this world. Further, each of the aspects like Risk Management, Incident Response, and Business Continuity Planning can be strongly supported or advocated through 77 Chapter 5■ IIon tnforma SySteS m management a policy driving the same with clear commitment from top management. However, as we have seen, such policies are merely put in place either because of the requirement of a standard or because of some customer insistence without much thinking and most of the time not revisited for years and are not referred to by the organizational personnel and losing the requisite sanctity. Hence, we have not focused in this chapter much on the policies except with regard to Incident Response Policy which we have included here as guidance. Risk Risk is the chance of something adverse happening which has negative consequences on the organization and in the context of this book on information security. Incident Any event of consequence to the organization where the organization faces potential loss or is exposed to potential loss can be considered as an incident. Loss can be monetary, business, reputation or loss of customers. Disaster Any grave situation which brings down the business partially or fully and which is of serious consequence to the organization can be considered as a disaster. These often may be on account of natural disasters but sometimes these may be on account of manmade activities like terrorism or at other times, they can be on account of severe security incidents like a severe infection of malware crashing all the critical servers. In a way, disasters can be considered more severe than an incident. Disaster Recovery Businesses are ongoing and they are meant to be ongoing or continuous entities. Businesses have competitors who always want to take away others’ customers or the market share. Businesses hence have to recover their businesses from each disaster speedily so that they are able to service their customers effectively before they plan to switch over to the competitor. Even though disaster recovery can mean any recovery from any disaster, many times it is referred to in the parlance of recovery of IT infrastructure and systems, which in today’s context performs a lead role in any business. Business Continuity All businesses are ongoing entities. It may be acceptable for a business which is non-critical to its customers to be shut down for a few days but a critical business like banking, health care, telecommunications, e-commerce, and others cannot be shut down for more than a few minutes to more than a few days depending on the business. Hence, they need to continue to sustain the continuity of the critical business may be at a lower scale or volume than the normal scale or volume. Business continuity assures that the plans and systems are in place to continue the business in spite of incidents or disasters. Business continuity includes business recovery post any disaster and is one of the important components as the speed at which you recover from downtime or disruption or disaster and continue business is critical for the success of any organization. 78 9 Chapter 5■ InformatIon SyStemS management Risk Management Risk is the chance that something can go wrong or of an adverse event taking place. In the context of information security, risk is something which can impact the availability, confidentiality, or integrity of business or personnel information. Examples of some of the common risks include: laptops being stolen and the data on them being stolen, a person tail gating somebody stealing some critical files, or a person who got the credentials through social engineering means gaining access to the server and copying confidential data, or somebody tapping into the network and modifying the messages being sent, or somebody physically stoning or ransacking the building during a riot, or that of natural hazards like floods. Threats are the risks. Risks need to be proactively managed. There are various methodologies to carry out risk assessments by the organization. Organizations are also free to come up with their own risk assessment methodologies depending upon their context and their experience. We are exploring one such methodology that is easy to use and practical and has been effectively used for some time. First, risks need to be identified. Then they need to be analyzed for the probability of their occurrence and the impact if they do happen. Based on the probability of their occurrence and the impact if they happen, the risk exposure or risk level has to be decided. Depending upon the risk exposure of the organization to any particular risk, the risk has to be either avoided, transferred, mitigated, or accepted. Risk can be accepted only when the organization is exposed to minimal risk that it can sustain. Where the risks are decided to be mitigated, additional controls to mitigate them have to be determined. It is normally necessary at this point to determine the additional controls, but it is also extremely important to ensure that these controls are effectively deployed and their continued effectiveness is monitored and ensured. Organizational internal and external context may vary from time to time, maybe due to a competitor environment or due to legal changes or may be due to the way the business is done or else due to the technological changes. The risks in the revised context need to be analyzed and additional controls need to be implemented as required to ensure that the organization continues to drive sufficient controls to protect information security. It is recommended that each organization has its own clearly defined risk assessment methodology which drives the risk assessment in the organization. This should cover the entire process of risk assessment including the acceptable risk exposure value and guidelines on various risk responses. Figure 5-1 illustrates the risk assessment life cycle. Risk Identification Periodical Re- Risk Analysis Risk Assessment Execution of Risk Risk Responses Treatment Plans Figure 5-1. Risk Assessment Life Cycle 79 Chapter 5■ IIon tnforma SySteS m management Again, we have seen some organizations using the asset value to calculate the total financial impact. We have seen this approach failing mostly because of lack of accurate asset value. Further, some organizations also try to assess the business impact of the risks in financial terms. Again, as we have seen, it turns out to be mostly guess work rather than based on uniform, good, prudent ways. In view of the preceding information, we have provided a simple, practical way that works for most of the organizations, which at the same time uses best in class practices from various guidelines and standards including from ISO/IEC 27001:2013 – Information Security Management System – Requirements. Identification of Risk The first step to identify the risks in the context of information security is to identify all the information assets of the organization. Information assets include the infrastructure, facilities, hardware, software, applications, utilities and tools, data, employees, contractors, and suppliers which are needed to run any business. Table 5-1 lists typical information assets that are found in organizations. Table 5-1. Typical Information Assets Function Information Asset Human Resources Employee Personal Records (with PII); Other Employee Records (Offer Letters, CVs, Offer Letters, Certificates, Performance Appraisal, etc.); Human Resources Management System; Employees (may be further categorized based on type of employees); Suppliers/Third Party Vendors; Recruitment Test Papers and Answer Keys; etc. Training Training Material; Training Quiz/Test Papers; Training Feedback and Analysis; Online Tools used for the Training; etc. Marketing & Sales Proposals; Marketing Strategies, Marketing Plans; Communications with the Customers including on the scope of new projects, pricing, etc.; Visit Plans of the departmental personnel; etc. Project Management & Proposals; Communications with the Customers; Customer Provided Property Project Teams (including such as Hardware; Customer Provided Information/Data; Project Artifacts; Product Development Teams / Applications; Utilities; Open Source Software; Third Party Software; Software Engineering Teams) Code Developed; New Concepts/Innovations yet to be patented; New Processes Invented; Design Documents, Architecture Documents; etc. Information Technology Desktops/Workstations; Laptops; Servers; Printers; Communication Equipment; CD/DVD Writers/Tape Drive; Backup Tapes; Scanners; External Hard-disks/USB Pen Drives; Original Licenses/License Keys; Network Cabling; Firewall, Router & Log Analyzer; ISP/External Connectivity; Physical Keys; Specific Servers like Anti-Virus Servers, Application Servers, Database Servers, Patch Management Server, FTP Server etc.; Other utilities used like Remote Connectivity Tools, Monitoring Tools, etc.; Logs of various servers/applications, system administrator activity logs; Encryption Keys; Root and other Administrative logins and passwords; etc. (continued) 80 Chapter 5■ InformatIon SyStemS management Table 5-1. (continued) Function Information Asset Finance & Legal Vendor Agreements/Contracts; Financial/Banking Details/Records; Statutory Records including Notices received, Cases Pending, etc.; Financial Instruments; Payroll, Tax and such other details; Digital Signatures; Login Ids and Passwords of Authorized Persons authorized to carry out different types of tasks on tools like SAP, Oracle Financials, etc.; Compliance Filings; Various reports filed with various statutory and regulatory agencies, etc. Quality Process Documents; Quality Records including Audit Records, Management Review Records and other records; Testing Records; Defect Details; Best Known Methods; etc. Note: a) The functions mentioned are only sample functions and the organizations may have more functions than the above or may be differently organized; b) Some of the above assets may be again bucketed into common, specific depending upon the differential risks e.g. management laptops have different risks compared to the clerical laptops; Customer-provided data like Patient Details, Credit Card details have different risks than the data without much sensitivity like generic data like details of the machines on the shop floor, etc., c) Again, the records / documents may be classified as hard copy records / documents or soft copy records / documents as they carry different risks; d) Tools / Utilities may have to be classified separately depending upon the purpose and their capability; etc.; e) Above list is not comprehensive. It is only illustrative. There may be hundreds of other documents / records / tools / utilities etc. which may be included which may also differ from organization to organization. The second step is to identify the threats the organization is exposed to with respect to each function within the organization. This may be done based on the historical data with the organization; or data obtained from the local and / or regional and / or national and / or international agencies or institutes of relevance or other sources of learned and reliable information. Additionally, expertise of the organizational employees, contractors, and suppliers is used. Another way is to identify the vulnerabilities the organization is exposed to like tail gating, lack of effective policies, lack of awareness / knowledge, technical vulnerabilities like security flaws in the utilities or applications used, the organization location, and so on, and then identify the threats which may exploit these vulnerabilities. Another way is to identify the threats first and then identify the vulnerabilities which may lead to such threats. However, it is necessary to identify various pairs of threats and vulnerabilities an information asset is exposed to. Each information asset may be exposed to different vulnerabilities which may lead to different threats or each threat may be due to different vulnerabilities. Also, different vulnerabilities may sometimes lead to the same threat. For example, a fire threat may result from storing old paper records and inflammable material in the organization, the kitchen being allowed to use electric or gas stoves, or weak wiring. A vulnerability of not having adequate awareness of policies may allow some non-employee to tail gate an employee which can lead the stranger to steal confidential files or papers, destroying the data center by planting a bomb, firing at the employees, or killing the employees. This makes clear the need for identifying different sets of vulnerabilities and threats. Some of the typical pairs of threats and vulnerabilities are listed in Table 5-2. 81 Chapter 5■ IIon tnforma SySteS m management Table 5-2. Threats and Vulnerabilities Threat Vulnerability Malicious Destruction Lack of Physical Security Theft and Fraud Lack of Physical Security Fire Lack of Environmental Protection Flood Lack of Environmental Protection Misplace / Loss of Documents Inadequate Document / File Handling Procedures Malicious Destruction Incorrect Access Rights Theft and Fraud Incorrect Access Rights Data Corruption & Loss of Data Lack of Backups Theft and Fraud Access of Production Data to Application Maintenance Engineers Theft and Fraud Lack of effective software change management leading to unauthorized changes Theft and Fraud Lack of Segregation of Duties Misuse of Equipment and Facilities Inconsistent Compliance with Security Policies Access of Facilities / Systems / Lack of Proper Exit Procedures Applications / Data by Ex-Employee or others and Possible Thefts and Frauds Technical Vulnerability Inadequate Configuration Undesirable Impact Inadequate Patch Validation Malicious Software Infection Lack of Adequate Monitoring Mechanisms Malicious Software Infection Technical Incompatibility Prey to Social Engineering Tricks Inadequate Security Awareness & Training Misuse of credentials Infrequent change of passwords / Weak Passwords Technical Failures Improper / Inappropriate Maintenance Intrusion / Unauthorized Data Access Inadequate Firewall / Router Policies Single Point of Failure Lack of Redundancy Service Deficiency Choice of Wrong Service Provider Note: a) Above list is only illustrative. It is impossible to cover all threats and vulnerabilities; b) The Threats and Vulnerability applicability depends upon the Information Asset. The third step is to identify each information asset, the pair of threat and vulnerability, the impact on each of the aspects of information security, that is, confidentiality, integrity, and availability. This can be a rating provided to each information asset, for each pair of threat and vulnerability, in terms of the impact on each of the information security aspects ( confidentiality, integrity and availability) that can be compromised or breached. Table 5-3 describes the 1 potential impact on security objectives. 82 Chapter 5■ InformatIon SyStemS management 1 Table 5-3. Levels of Impact on Security Objectives Security Objective Low Impact Medium Impact High Impact Confidentiality The unauthorized The unauthorized disclosure The unauthorized disclosure disclosure of information of information could of information could be could be expected to have be expected to have a expected to have a severe or a limited adverse effect on serious adverse effect on catastrophic adverse effect organizational operations, organizational operations, on organizational operations, organizational assets, or organizational assets, or organizational assets, individuals. individuals. or individuals. Integrity The unauthorized The unauthorized The unauthorized modification or modification or destruction modification or destruction destruction of information of information could of information could be could be expected to have be expected to have a expected to have a severe or a limited adverse effect on serious adverse effect on catastrophic adverse effect organizational operations, organizational operations, on organizational operations, organizational assets, organizational assets, or organizational assets, or individuals. individuals. or individuals Availability The disruption of access The disruption of access The disruption of access to to or use of information to or use of information or use of information or an or an information system or an information system information system could be could be expected to have could be expected to have expected to have a severe or a limited adverse effect on a serious adverse effect on catastrophic adverse effect organizational operations, organizational operations, on organizational operations, organizational assets, organizational assets, or organizational assets, or individuals. individuals. or individuals. Amplification A limited adverse A serious adverse effect A severe or catastrophic effect means that, for means that, for example, adverse effect means that, example, the loss of the loss of confidentiality, for example, the loss of confidentiality, integrity, integrity, or availability confidentiality, integrity, or or availability might: might: (i) cause a significant availability might: (i) cause a (i) cause a degradation in degradation in organizational severe degradation in or loss organizational capability capability to an extent and of organizational capability to an extent and duration duration that the organization to an extent and duration that the organization is able to perform its primary that the organization is not is able to perform its functions, but the able to perform one or more primary functions, but effectiveness of the functions of its primary functions; the effectiveness of the is significantly reduced; (ii) result in major damage functions is noticeably (ii) result in significant to organizational assets; reduced; (ii) result in minor damage to organizational (iii) result in major financial damage to organizational assets; (iii) result in significant loss; or (iv) result in severe assets; (iii) result in minor financial loss; or (iv) result or catastrophic harm to financial loss; or in significant harm to individuals involving loss of (iv) result in minor harm to individuals that does not life or serious life threatening individuals. involve loss of life or serious injuries. life threatening injuries. 83 Chapter 5■ IIon tnforma SySteS m management Low impact on any security objective is given a value of 1, medium impact on any security objective is given a value of 2 and high impact on any security objective is given a value of 3. If any security objective is not applicable to the information asset under consideration then it is given a value of 0. For each information asset, for each pair of threat and vulnerability, the impact value for confidentiality plus the impact value for the integrity plus the impact value for availability gives the total asset impact value. Asset impact is optionally categorized as C1, C2, C3 based on the following total asset impact values listed in Table 5-4. Table 5-4. Asset Category Classification Based on Asset Impact Value Asset Impact Category Total Asset Impact Value C1 – High impact asset Total Asset Impact Value of 7 or 8 or 9 C2 – Medium impact asset Total Asset Impact Value of 4 or 5 or 6 C3 – Low impact asset Total Asset Impact Value of 1 or 2 or 3 The fourth step is to identify the controls already implemented by the organization to manage this risk. These controls may be physical security like security guards; awareness sessions wherein the employees are made aware of the do’s and don’ts or specific steps to be taken to avoid, control, and mitigate the risks; or implementation of a tool in the organization like a firewall that eliminates such a risk. Risk Analysis Risk analysis is the next important step. At the end of the risk analysis we need to quantify the risk in terms of quantified risk exposure. This is different from the impact levels on confidentiality, integrity, and availability we discussed in the earlier paragraphs. For a particular information asset, for each of the pair of threat and vulnerability, we identify the actual impact on the business. For example, a banking server compromised and misused may impact the entire business severely, including potential loss of customer confidence, reputation loss, loss of data integrity, or monetary loss. Then we determine the probability of this risk (also known as the likelihood of risk), as shown in Table 5-5. Probability of the rating is from 1% to 99%. A probability of 100% means that the risk is already true and has already occurred. Table 5-5. Risk Probability Ratings Probability Description Probability Value Almost certain Several times a week or day 5 Likely More than once per month 4 Moderate Up to several times a year 3 Unlikely 2–5 times every 5 years 2 Rare Unlikely to occur 1 Then for each pair of threat and vulnerability we identify the possibility of detection and assign a rating in a scale of 1 to 5. However, here the lower the possibility of detection, the higher the rating and the higher the possibility of detection the lower the rating, as shown in Table 5-6. 84 Chapter 5■ InformatIon SyStemS management Table 5-6. Possible Detection Ratings Possibility of detection Description Probability Value Extremely Low Probability of detection is 0 to 20 % 5 Low Probability of detection is 21 to 40 % 4 Medium Probability of detection is 41 to 60 % 3 High Probability of detection is 61 to 80 % 2 Extremely High Probability of detection is 81 to 100 % 1 Once all three (total asset value, probability of occurrence and the rating for the possibility of detection) are determined for each of the threat and vulnerability pairs, then the risk exposure is quantified using the following formula: Risk Exposure = Total Asset Impact Value x Probability of Occurrence x Possibility of Detection The organization should have decided the risk exposure it considers as acceptable as a part of the risk assessment methodology adopted by it. It should not be too high that it leads to acceptance of every risk and it should not be too low that it leads to compulsory mitigation, avoidance, or transfer of every risk. Organizations are free to set their own acceptable risk xposure threshold depending upon their risk appetite. Risk Responses For each pair of threat and vulnerability, the calculated risk exposure is compared with the risk exposure considered acceptable to the organization (i.e., acceptable risk exposure). Where the risk exposure is less than the acceptable risk exposure, the risks are normally accepted by the organization and no further action is taken. Acceptable risk exposure is decided by the organization as per its risk assessment methodology. Normally, this is the value of risk exposure below which the organization perceives the risks need not be focused on as the risks are very low and not worth pursuing. There may be some other risks that the organizational management may want to consciously accept, such as the organization may allow mobile phones with cameras to be brought into the organization even though there is a risk that the cameras may be misused. The risk exposure in this case may be more than the acceptable risk exposure value. But, the organization may want to accept the risk because of its belief in the employees, considering other positive uses of mobile phones, not to demotivate the employees. Such practices of accepting the risk or not accepting the risk based on a specific context differ widely from organization to organization. As we have seen, some organizations may be very conservative in accepting the risks whereas other organizations may be relatively liberal in this regard when it particularly relates to inconveniencing the employees. If the risk exposure is more than the acceptable risk exposure value then either the risk has to be avoided by mistake proofing (i.e., by implementing such measures that eliminate the possibility of such a risk occurring at all, such as if there is an unused entry or exit – mistake proofing is done by locking and sealing it permanently), the risk has to be transferred to others, or the risk has to be mitigated. Some of the possibilities of the transference of risk is to take up insurance for the risk of loss from fire or transference of risk of ineffectiveness or inefficiency through outsourcing of the work to the experts in that area. However, transference of risk is not possible in most of the cases. Where the risks are not possible to be either avoided or to be transferred then they need to be mitigated. Mitigation is carried out by determining additional controls to be implemented. These controls may be awareness training, or may be implementation of a tool to monitor and provide alerts so that timely actions can be taken, or may be implementation of methods and techniques like encryption, or may be implementation of a security certificate for the URL, or may be introduction of additional validations and / or exception flows in the application software, or implementation of better processes. The additional controls implemented should be such that they have either the capability to reduce the probability of occurrence or reduce the impact or increase the probability of detection or a 85 Chapter 5■ IIon tnforma SySteS m management combination of these. These additional controls or actions implemented should have to be assigned in such a way that there is high probability that the risk exposure is reduced below the acceptable value of risk subsequent to the implementation of the additional controls. All the additional controls to be implemented including the risk avoidance and risk transfer actions have to be assigned to relevant owners for effective actions. Perceived risk exposure post implementation of additional controls should be collated against the existing risk to understand whether the additional controls are likely to bring the risk below the acceptable risk exposure value. Where it is perceived that the additional controls are unlikely to reduce the risk exposure below the acceptable value, the risks are to be brought to the attention of senior management of the organization and approval has to be obtained for bearing the residual risk. Execution of the Risk Treatment Plans The risk treatment plans (actions on account of earlier steps) are assigned through an Excel sheet or organizational action tracking tool to the respective owners and are tracked through the same on a regular basis. It is essential that the requisite focus and attention is provided by the management to ensure that these actions are invariably taken. Otherwise, the entire risk management exercise will be futile. Risk owners not only execute the necessary actions, but also ensure that the necessary processes to implement them effectively are defined and everybody (as relevant and required) is trained on those processes. Awareness of the risks and the actions required to be taken by all (as relevant and required) are also made known to everybody. The assigned action owners, upon implementation of the actions, check for the revised probability of occurrence, revised impact rating, and revised rate of detection. Where the risk exposure upon effective implementation of controls has not led to lowering the risk exposure below the acceptable risk value, then additional controls have to be implemented. Management has to be kept informed of the necessity and implementation of such actions so that requisite resources are deployed and the support is accorded for their effective implementation. The Importance of Conducting a Periodic Risk Assessment The organizational risk scenario changes when the business changes, the infrastructure changes, the technology deployed changes, and the competence of the personnel changes. These changes cannot be ignored, as these have the potential to impact the effectiveness of the controls already implemented and change the earlier risk profile of the organization. Whenever such significant changes are carried out by the organization or on a periodical basis (ideally on a six month to maximum of annual basis), re-risk assessment has to be carried out across the organization, and additional controls as required have to be determined and implemented. Proactive approach in this regard ensures that the effectiveness of the controls is maintained. Figure 5-2 shows detail from a template that may be used for a risk assessment. Figure 5-2. Risk Assessment Template (detail) 86 Chapter 5■ InformatIon SyStemS management Incident Response Before we discuss incident response, we need to be able to differentiate between three aspects: information security weakness, information security event, and information security incident. To cite an example, suppose an employee tailgates another employee without swiping in his access card. This is a security event but cannot be considered as a security incident as the employee would have otherwise also come inside by obtaining a temporary access card if he had forgotten his access card. Suppose the tailgating is done by an ex-employee or a stranger. Then it is a security incident as it has the potential of leading to loss or disruption etc. Information security weakness in this case may be that once the employee has swiped his access card and gets into the organization the door takes a lot of time to close and lock down. Information security weakness may be that a utility you are using in the organization has a security loophole. Information security weaknesses if left unattended may lead to information security incidents. All the information security events may not be information security incidents but need to be evaluated to check whether they point towards a possibility of an information security incident. For example, a log shows that somebody was trying to access one of our servers from outside the organization. On checking, you may find that it was one of the employees who had authorization to have access to that information. Hence, it was an information security event which you cannot ignore, but upon evaluation you found that it is not an information security incident. Potential security incidents need to be proactively protected against but some of the security incidents cannot be protected against like the unknown vulnerabilities in an application or operating system or a new virus or worm attack. However, where it is not possible to proactively protect against these we need to have alerting or detective mechanisms which alert us to the possibility of a security incident. For example a newly downloaded program is behaving suspiciously as found by your anti-virus or anti-malware tool. You need to check for what kind of suspicious activities are carried out by it, where it was downloaded from, and whether it is performing as intended, before you decide to act on it. Firewalls, IDS/IPS, anti-virus, and anti-malware software are some of the tools / utilities which provide you detective controls. Once a security incident is identified, it cannot be left alone without attending to it. If the security incident was the tailgating by an ex-employee / a stranger or an application functionality behaving erratically, then the security incident has to be investigated to find out the root cause(s) for the same, so that corrective actions can be determined and taken to either fix the root cause(s) or mistake proof the issue itself. If the incident is a serious one like a worm attack or a virus attack with serious implications then the actions or response has to be quick to contain the issue from spreading and containing the consequential damage. In view of such a serious situation, having an effective incident response is necessary for all organizations. In order to achieve this objective, all organizations need to follow a well ordered Incident Response Life Cycle and have a comprehensively detailed Incident Response Plan. Incident Response Life Cycle defines various phases through which an incident has to be managed for incident responses to be effective not only in containing and spreading the effects, but also avoid recurrence of same or similar incidents. Incident Response Plan is the output of the Incident Response Preparation Phase and provides a well thought-out and well-articulated Incident Response Plan which enables the organizations to deal with incidents effectively and efficiently. Figure 5-3 illustrates the Incident Response Life Cycle. 87 Chapter 5■ IIon tnforma SySteS m management Incident Response Policy, Plans & Incident Incident Processes Response Detection & Incident Response Team Preparation Analysis Training (1) (2) Risk Assessment Etc. Incident Response Life Cycle Incident Post-Incident Containment, Activity Eradication & (4) Recovery (3) 2 Figure 5-3. Incident Response Life Cycle Incident Response Policy, Plan, and Processes Incident Response Policy should be put in place by management of the organization demonstrating its commitment to the Incident Response. This policy directs and provides guidance to the entire organization and provides the base for the Incident Response Plan and related processes. Incident Response Policy Incident Response Policy provides management direction towards Incident Response and also emphasizes the management’s commitment to the same and highlights the “musts” as far as Incident Response is concerned. Incident Response Policy covers the following areas. Purpose and Scope of the Policy This should clearly define the purpose of incident response, namely, what the organization wants to achieve through incident response. This should also describe the scope of incident response in the organization. The scope can be the 2 entire organization or a particular unit or a specific group of units and the type of incidents and circumstances. It highlights management’s commitment and addresses what the management feels as mandatory to be followed with regard to incident response. 2 Definition of Information Security Incidents and Related Terms From organization to organization, the definition of information security incidents can differ. It is necessary that the organization clearly defines what it means by an incident and related terms like incident response, incident recovery, and incident response team. 88 Chapter 5■ InformatIon SyStemS management Organizational Structure, Roles, Responsibilities, and Authorities Any policy cannot be implemented effectively and efficiently unless there is a proper structure to support it in the organization. The structure should be composed of clear roles with clear responsibilities. For an incident response, many times somebody needs to act expeditiously without any bureaucratic approval cycle in order to carry out immediate containment or control activities. Therefore it is necessary that some of the roles have to be provided with authorities which may be beyond their normal authorities. An organization’s structure, roles, responsibilities, and designated authorities have to be clearly defined and described so that there is no ambiguity, and that no confusing actions are taken. All the people in the organization have to be clearly informed of the organization structure, roles, and responsibilities as the incident response has to be quick and requires coordination between various functions and personnel of the organization and cannot happen without this clarity across the organization. Otherwise, egos and organizational bureaucratic setups can create hurdles during an incident response which can delay the response significantly leading to a higher level of disruption or damage or theft. The roles, responsibilities, and authorities should provide the authority to the incident response team even to confiscate the equipment or disconnect the equipment and 2 to monitor and investigate suspicious activities. This also should make it clear what and which types of communications to the outside world or to the related agencies are permitted and who is permitted to carry out the same. Incident Response Teams constitute personnel with complementary skills, experience, and capabilities. Head of the Incident Response Team is normally vested with significant authority to make decisions at times of need to effectively contain and recover from incidents. Ratings of Incidents All incidents do not require the same level of attention. Some of the incidents may be localized incidents and may have a local impact. Some may be organization-wide incidents with organization-wide impact. Some incidents may impact critical business areas and others may impact non-critical business areas. Some incidents may be easy to be responded to while some others may be very complex which can be responded to only by experts. Some incidents may have high impacts and some incidents may have low impacts on the organization. In order that the organizational personnel and the incident response team do not get confused, clear guidelines have to be provided as to the severity of various types of incidents. Speed of action required to be taken and the priority depends upon the severity rating of the incident. Measurements Any critical activity in the organization has to be measured to understand either its effectiveness or efficiency or both of these. The measurements provide us with the clear view of where we stand with respect to performance and bring out the opportunities for improvement. But, measurements to be made should be appropriate and should be defined in clear terms so that the measurements actually provide us the information as per the intended objectives of these measurements. Incident Response Plan The Incident Response Plan should clearly define what is considered as an incident in the organization. Second it should clearly identify the potential types of incidents the organization is exposed to based on the infrastructure of the organization, IT architecture of the organization, types of operating systems, and tools and utilities used by the organization. Third, it has to clearly describe what needs to be done if a new and unanticipated incident is faced by the organization. This may include who needs to be notified, and who will make a final call as to what needs to be done. The Incident Response Plan also has to specify external agencies or forums if any need to be informed or consulted with. The Incident Response Plan covers the following areas. 89 Chapter 5■ IIon tnforma SySteS m management Purpose and Scope Purpose of the Incident Response Plan and the scope as to which type of incidents, pertaining to which location and which functions is made clear in this section. Strategies, Goals, and Approach to Incident Response Incident response strategies, goals, and approaches including the incident monitoring strategies, incident response strategies, strategies related to organization to effectively handle incidents including the team composition, internal and external coordination, and total or partial outsourcing of the incident response need to be clearly planned for and appropriate responsibilities are to be assigned to named personnel with appropriate backups so that there is a guarantee that in case of any incidents, they are handled effectively. Internal and External Communication Plan The communication for identifying the incidents, declaring the incidents, and responding to the incidents needs to be clear and should come from the persons authorized to carry out such communications. The communications should be within the defined boundaries and the communications should be appropriately worded. The clarity as to how internal communications need to be handled and how the external communications need to be restricted are to be clearly planned for. 2 Plan for the Incident Response Capability An organization requires adequate, suitable incident response capability in order to be effective and efficient in incident response. Any organization has to assess its current incident response capability in terms of availability of techniques, tools, and utilities and the resource competence including the skills to handle incidents. If it does not have the internal capability either the option to outsource or to acquire the capability through new recruitments has to be looked into. Plans to have appropriate, adequate, and suitable incident response capability have to be clearly delineated with action responsibility and target dates clearly assigned. Measurement of Incident Response Capability and its Effectiveness It is necessary to measure the incident response capability of the organization including that of the outsourced portion of the incident response capability. Periodic assessment of the same will close up the gaps between the expectations and the current realities. Organizations are not static. People with expertise and assigned key responsibilities may leave the organization. The same holds true for outsourced organizations. At the time of outsourcing, the particular organization may have excellent capabilities but over a period of time it is possible that it would have lost the capability or would have had its capability reduced because of the attrition of key people. Further, the new technologies being implemented or changes to the technologies being implemented can make the requisite incident response capability differ from what was originally planned. Further, we also need to measure the effectiveness of the implemented capability. These may be possible to be measured by the responses that have been provided to the incidents which have occurred. Similarly, it may be possible to test some of the incident response through mock scenarios and testing of the possible incidents. It is important to consider the various types of incidents possible and how they have to be handled so that there is no ambiguity. At least processes have to be clearly defined in respect to high impact incidents. These may be based on the common attack vectors. 90 Chapter 5■ InformatIon SyStemS management Integration with the Other Plans of the Organization An organization may have other plans like Risk Management, Disaster Recovery, and Business Continuity Plans. It is necessary that all these plans are integrated in such a way that each plan complements the other plans and does not contradict the other plans. Incident Response Processes Incident response processes are the important elements for the success of the incident responses. Various possible incidents from virus infection to malware infection to server crashes to denial of service attacks to bomb threats to many such possible incidents have to be thoroughly planned. Where the possibility of these incidents is high, the incident responses have to be discussed and planned for by having appropriate incident response processes. These processes have to be detailed enough with various possible scenarios and appropriate responses. These processes have to detail how these incidents are identified and analyzed. These need to be supported additionally by templates, forms, and checklists as relevant so that it is easy to implement the expectations of these incident response processes effectively. Incident Response Teams Incident Response Team(s) is/are an important component and highly influence the success or failure of the effectiveness and efficiency of the incident response. This team requires the knowledge, experience, and skills to ensure that the incident detection, incident containment, and incident eradication are carried out effectively and efficiently. Incident Response Team(s) can be dedicated teams or may be “on call” teams depending upon the criticality of the business, exposure of the organization to the incidents, competence of the IT resources, and resilience of the information security infrastructure. Incident Response Team structuring based on distribution of the Responsibilities Incident Response Teams are normally structured based on best fit distribution of the responsibilities among various centers. 2 Centralized Incident Response Teams Centralized Incident Response Teams are usually suitable for smaller organizations with less geographical spread. In big organizations such a structure can lead to lack of effective coordination due to various reasons like cultural reasons, internal political reasons, and bureaucratic decision making. 2 Distributed Incident Response Teams Distributed Incident Response Teams are suitable for multi-business, multi-locational organizations with distributed IT infrastructure. Each of these centers or group of centers may have their own Incident Response Team. In today’s world, where each center is connected to the other centers and where the same business is carried out in various geographies and where the IT infrastructure is distributed based on efficiency and competency, it is necessary to have a person or group coordinating the efforts of these various Incident Response Teams as the same incident may affect multiple locations or an incident at one center may impact the business carried out at other centers. 91 Chapter 5■ IIon tnforma SySteS m management Hybrid Incident Response Teams It is possible that the expertise to handle the incidents in not uniformly distributed across various locations of an organization. In such a case it is possible to constitute a Central Incident Response Team at the prime location of the organization or technological hub of the organization with Incident Response Teams at the other centers as required. Incident response for some of the smaller centers or the centers which may lack the requisite expertise may be directly taken care of by a Central Incident Response Team. In such a model, it is possible to authorize the individual Incident Response Teams at various centers to act independently in case of local incidents and keep such incidents reported to the Central Incident Response Team. But, in case of purely local incidents the Central Incident Response Team assumes the advisory role if any support is required by the local Incident Response Teams. All the incidents which have impact across the businesses or locations or of higher impact are handled by the Central Incident Response Team. Necessary actions are directly taken by the Central Incident Response Team or as per the directions of the Central Incident Response Team by the distributed Incident Response Teams. Incident Response Team Structuring Based on who Constitutes the Teams The teams have to be constituted with appropriate competent resources. This depends upon the business, technology infrastructure, tools, and utilities used. If the team is not composed of competent resources it is possible that incidents may not be recognized sufficiently early or incident response may be delayed or incident response may not be effective. All organizations may not have in-house competence for effective and efficient incident response. They may have to complement internal competence with external expertise to effectively deal with incident response. Again the Incident Response Team can be constituted with full-time members or part time “on call” members. This depends upon the business criticality as well as IT infrastructure robustness, probable incidents, and IT resilience. The pros and cons of each of these structures have to be evaluated in the context of the organization and then an appropriate 3 decision has to be made based on the well-evaluated and well-considered trade-off . Fully Employee Constituted Incident Response Teams If the organization has adequate internal competence then the Incident Response Team can be constituted internally. But, if the Incident Response Team is required to be available 24x7 and required to be deployed as it is, it is better to constitute a separate Incident Response Team with the experts specifically recruited by the organization. However, if it is enough to constitute an “on call” Incident Response Team then it is more effective to constitute the team internally with the expertise already available in-house. Fully Outsourced Incident Response Teams Here, the organization arranges for the entire team to be constituted by outside experts. Usually this may be through a single outsourced entity. However, it may be a group of organizations to which the outsourcing is done with complementary expertise, even though such a scenario is seen less in practice. This type of team constitution is usually found in smaller organizations for which it is difficult to internally source the requisite expertise. It is possible that such teams may have a tough time providing for effective and efficient Incident Response sometimes because of bureaucratic responses or hindrances or because of lack of effective authority delegated to them. Hybrid Teams: Partially Constituted by Employees and Partially Constituted by Outsourced Contractors Here, the organization constitutes its Incident Response Team with chosen internal employees and chosen outsourced contractors. This model is likely to work the best because the internal expert resources are complemented through other rare / non-available skills from the outsourced contractors. As the internal employees constitute a good portion of the team bureaucratic hindrances or lack of authority impeding effectiveness and efficiency of the incident response may not be an issue in this case. 92 Chapter 5■ InformatIon SyStemS management Ensuring Effectiveness of Incident Response As discussed earlier, incident response is not always easy for the following reasons: • The actual incident may be the one that was not anticipated • Key members of the incident response team and their backups may not be available when the incident actually happens • Incident response plan is beautifully drafted but the stakeholders are not trained effectively on the plan • Incident response teams are not staffed suitably or adequately • Incident response plan was not updated for a long time and has become non-useful because of the changes to the infrastructure and systems over a period of time • Incident Response Processes are outdated and are not in sync with the currently deployed technology For effective incident response execution the following steps have become essential: 2 Preparation Any battle is half won before it begins if the preparations are done well. Similarly, preparation is very important to 2 ensure the effectiveness of the incident response. Following are the important aspects of the preparation: • Risk assessment and identification of the risk mitigation steps to overcome the non-acceptable risks including the threats likely to lead to incidents • Training the resources on the possible incidents and providing them the awareness and knowledge to enable them to effectively prevent the incidents, such as virus prevention programs, strong password, or encryption training • Effective formulation of the Incident Response Team constituting suitable and appropriate structure and members with the requisite capability • Well thought out and preventive IT infrastructure and physical security infrastructure • Effective Incident Response Policy, Incident Response Plan, and supporting Incident Response Processes • Validation of the Incident Response Plans and Incident Response Processes to ensure that they work when required • Training on the execution of the Incident Response Plans • Regular update to the Incident Response Policy, Incident Response Plan, and Incident Response Processes in tune with the changes to or at the organization • Configuring the setup including those of tools / utilities used by the organization appropriately 2 Important aspects to be considered during the preparation are: • Internal and external contact details including those of on-call members, Incident Response Team members, and external agencies. • Incident Reporting Mechanisms including the e-mail ids, contact phone numbers, or tools / utilities through which incidents can be reported. 93 Chapter 5■ IIon tnforma SySteS m management • Incident Response War Room: This is the place designated for the Incident Response Team to operate. Primarily the Incident Response Team Leader directs and guides the team from here and can be contacted here. This room is provided with multiple telephone lines and other accessories to ensure effective communication in and out of this War Room. • Incident Tracking Tool/Utility: Incidents need to be tracked including the status of the incidents and various actions taken at various places to ensure that the actions are executed as proposed. This is the incident repository which needs to be kept updated and which provides the Incident Response Team Leader to provide accurate and correct information related to incident status to internal and external stakeholders, as relevant. • Readily available or accessible Incident Response Plan and Processes • Secure Storage Facility: This is provided to store and preserve the evidence obtained during incident investigation. • Mobiles or Tablets: These enable effective communication during the incident among internal and external stakeholders. • Incident Analysis Hardware and Software such as Forensic Workstations, Backup Devices, Laptops and/or desktops, Servers, Portable Printers, Forensic Software, Digital Cameras, Video / Audio Recorders, Blank Media and other tools / utilities as relevant which help out in 2 effectively analyzing the incidents; analyzing, collecting, and preserving the evidence. • Incident Analysis Resources including List of Ports, Network Diagrams / Maps, Configuration Management Database, Operating System and Database and Application related 2 documentation. • Incident Mitigation Software which enables restoration and recovery of Operating Systems, Applications enabling IRT to create clean OS and application images. 2 Incident Detection 2 Incident detection is the next important step. All the incidents are not possible to be anticipated. However, there are some common threads among certain groups of incidents and these are normally known as Common Attack Vectors. These Common Attack Vectors enable us to understand and use the possibility of providing more specific responses. 2 Table 5-7 lists the Common Attack Vectors. 2 Table 5-7. Common Attack Vectors Common Attack Vector Description External / Removable Media An attack executed from removable media or a peripheral device—for example, malicious code spreading onto a system from an infected USB flash drive Attrition An attack that employs brute force methods to compromise, degrade, or destroy systems, networks, or services (e.g., a DDoS intended to impair or deny access to a service or application; a brute force attack against an authentication mechanism, such as passwords, CAPTCHAS, or digital signatures) Web An attack executed from a website or web-based application—for example, a cross-site scripting attack used to steal credentials or a redirect to a site that exploits a browser vulnerability and installs malware (continued) 94 Chapter 5■ InformatIon SyStemS management Table 5-7. (continued) Common Attack Vector Description Email An attack executed via an email message or attachment—for example, exploit code disguised as an attached document or a link to a malicious website in the body of an email message Impersonation An attack involving replacement of something benign with something malicious— for example, spoofing, man in the middle attacks, rogue wireless access points, and SQL injection attacks all involve impersonation Improper Usage Any incident resulting from violation of an organization’s acceptable usage policies by an authorized user, excluding the above categories; for example, a user installs file sharing software, leading to the loss of sensitive data; or a user performs illegal activities on a system Loss or Theft of Equipment The loss or theft of a computing device or media used by the organization, such as a laptop, smartphone, or authentication token Other An attack that does not fit into any of the other categories 2 Precursors and Indicators of Incidents It is most difficult to understand whether the incident is occurring or has already occurred and the type, extent, and / or magnitude of the incident. Precursors provide an indication that there is a possibility of an incident happening, such as if there is an email or telephonic threat to the organization, a terrorist attack, or there have been failed attempts made to break into a critical system. Indicators provide the signals that the incident is either occurring at this point of time or has already occurred, such as file checksums do not match, some data is leaked and published on a public website, somebody has already defaced the website, an increased number of files are getting corrupted day by day, or higher than normal utilization of the traffic is observed. It is possible that some of these indicators may be false positives and would have happened because of an employee’s unintended mistake which was not even observed by the employee concerned or because of a wrong restoration by oversight or a wrong update. We may not have either a precursor or an indicator in case of some of the incidents, such as a new exploit of a new vulnerability just uncovered by a hacker or a misconfiguration newly exploited by an internal knowledgeable employee. However, these precursors and indicators, when available, provide us an opportunity to speed up our responses and many times provide us the opportunity to either stop an incident from happening or reduce the impact of the incident. Sources of Precursors and Indicators 2 Some of the sources of the precursors and indicators are described in Table 5-8. 95 Chapter 5■ IIon tnforma SySteS m management 2 Table 5-8. Common Sources of Precursors and Indicators Source Description Alerts IDPSs IDPS products identify suspicious events and record pertinent data regarding them, including the date and time the attack was detected, the type of attack, the source and destination IP addresses, and the username (if applicable and known). Most IDPS products use attack signatures to identify malicious activity; the signatures must be kept up to date so that the newest attacks can be detected. IDPS software often produces false positives—alerts that indicate malicious activity is occurring, when in fact there has been none. Analysts should manually validate IDPS alerts either by closely reviewing the recorded supporting data or by getting related data from other sources. SIEMs Security Information and Event Management (SIEM) products are similar to IDPS products, but they generate alerts based on analysis of log data (see below). Antivirus and antispam software Antivirus software detects various forms of malware, generates alerts, and prevents the malware from infecting hosts. Current antivirus products are effective at stopping many instances of malware if their signatures are kept up to date. Antispam software is used to detect spam and prevent it from reaching users’ mailboxes. Spam may contain malware, phishing attacks, and other malicious content, so alerts from antispam software may indicate attack attempts. File integrity checking software File integrity checking software can detect changes made to important files during incidents. It uses a hashing algorithm to obtain a cryptographic checksum for each designated file. If the file is altered and the checksum is recalculated, an extremely high probability exists that the new checksum will not match the old checksum. By regularly recalculating checksums and comparing them with previous values, changes to files can be detected. Third-party monitoring services Third parties offer a variety of subscription-based and free monitoring services. An example is fraud detection services that will notify an organization if its IP addresses, domain names, etc. are associated with current incident activity involving other organizations. There are also free real-time blacklists with similar information. Another example of a third-party monitoring service is a CSIRC notification list; these lists are often available only to other incident response teams. Logs Operating system, service and Logs from operating systems, services, and applications (particularly audit- application logs related data) are frequently of great value when an incident occurs, such as recording which accounts were accessed and what actions were performed. Organizations should require a baseline level of logging on all systems and a higher baseline level on critical systems. Logs can be used for analysis by correlating event information. Depending on the event information, an alert can be generated to indicate an incident. (continued) 96

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.