Eze Castle Integration https://alpha-week.com/ en Seven Steps To Create A Business Continuity Plan https://alpha-week.com/seven-steps-create-business-continuity-plan <!-- THEME DEBUG --> <!-- THEME HOOK: 'field' --> <!-- FILE NAME SUGGESTIONS: * field--node--title--features.html.twig x field--node--title.html.twig * field--node--features.html.twig * field--title.html.twig * field--string.html.twig * field.html.twig --> <!-- BEGIN OUTPUT from 'core/modules/node/templates/field--node--title.html.twig' --> <span>Seven Steps To Create A Business Continuity Plan</span> <!-- END OUTPUT from 'core/modules/node/templates/field--node--title.html.twig' --> <!-- THEME DEBUG --> <!-- THEME HOOK: 'field' --> <!-- FILE NAME SUGGESTIONS: * field--node--created--features.html.twig x field--node--created.html.twig * field--node--features.html.twig * field--created.html.twig * field--created.html.twig * field.html.twig --> <!-- BEGIN OUTPUT from 'core/modules/node/templates/field--node--created.html.twig' --> <span>Fri, 11/30/2018 - 08:58</span> <!-- END OUTPUT from 'core/modules/node/templates/field--node--created.html.twig' --> <!-- THEME DEBUG --> <!-- THEME HOOK: 'field' --> <!-- FILE NAME SUGGESTIONS: * field--node--body--features.html.twig * field--node--body.html.twig * field--node--features.html.twig * field--body.html.twig * field--text-with-summary.html.twig x field.html.twig --> <!-- BEGIN OUTPUT from 'themes/gavias_vinor/templates/fields/field.html.twig' --> <div class="field field--name-body field--type-text-with-summary field--label-hidden field__item"><p><span><span><span><span>Global IT provider, Eze Castle Integration, has been running an educational program for October’s ‘Cyber Security month’ and on Thursday, October 25th, hosted a webinar entitled ‘7 Steps to Create a Business Continuity Plan’. AlphaWeek is publishing edited transcripts of these webinars. The speakers are Matt Donahue, Business Continuity and Data Privacy Consultant, and Steve Banda, Senior Product Manager, Eze Castle Integration, and the webinar was moderated by Olivia Munro, Senior Marketing Specialist, Eze Castle Integration.</span></span></span></span></p> <p><span><span><strong><span><span><span>Why having a business continuity plan is so important</span></span></span></strong></span></span></p> <p><span><span><strong><span><span><span>Matt Donahue:</span></span></span></strong><span><span><span> Let's start by looking at what business continuity is at a high level. It's typically documentation and resources that will help your firm respond to different types of issues that come up, whether these are outages caused by human error or failure of critical systems, to minimise the negative effects of the disruptions or those outages. </span></span></span></span></span></p> <p><span><span><strong><span><span><span>Step one</span></span></span></strong><span><span><span> is understanding the regulatory landscape that your business sits in. There are always going to be different requirements depending upon the business that you have. Some of them might be from federal bodies, some might be from an international place, some might be self-regulatory, but a lot of times, it's just good practice to have a business continuity plan, even if it's not necessarily needed from a regulatory overview; there is a lot of pressure from investors or people performing due diligence on your fund because they understand that it's important to have these things, and people might not want to work with you if you haven't focused time and effort into these. </span></span></span></span></span></p> <p><span><span><strong><span><span><span>Step two</span></span></span></strong><span><span><span> is risk assessment. Whether it's a business continuity plan or an information security plan, looking at the different risks is helpful. Evaluate your company's risks and exposures. It's not something that's supplied via a single software solution, or something that's just done through discussions; it's usually a combination of a few different things, but you want to look at the different potential impact, to the businesses, based on typical situations you're going to be dealing with. You have to consider people, technology, your business office location. Look for single points of failure, or your most common situations; understanding what might be critical in one unit and not for others within the organisation. </span></span></span></span></span></p> <p><span><span><strong><span><span><span>Step three</span></span></span></strong><span><span><span> is business impact analysis. This is a really helpful tool to help you understand how different business units function, what's critical to them, the different tools they use, and what their dependencies are. When you're carrying out a business impact analysis you want to look at critical applications, their critical functions, when things need to be recovered by, and what the expectations are, and from whom. Trying to get the whole picture for that specific business impact analysis for each unit is important, and you want to try to pull those all together to understand that what might be important for operations and finance is not that valuable from an accounting standpoint, for example. When you can put all of this information together, alongside the risk assessment and the business impact analysis, it helps to guide you to identifying some gaps that you can incorporate into the plan.</span></span></span></span></span></p> <p><span><span><strong><span><span><span>Steve Banda: </span></span></span></strong><span><span><span>Once the risk assessment and the business impact assessment are completed, it's time to start to think about <strong>step four</strong>, the overall strategy. Incorporating multiple perspectives is critical to making sure that all departments have had their view considered. It’s important that this doesn’t mean for each separate department, but it means all departments views are mapped to the overall holistic strategy of the company and what's important to the organisation. ensuring that all stakeholders have an input is critical. This information has to be available and easily accessible by your staff, especially when there's a disaster. Ensuring that this information is stored safely and reliably on an ongoing basis is essential; some sort of offsite cloud secure web repository could be employed here, and then ensuring that you can get it when you need it. Finally, we really do recommend that you have an executive sign off on the overall plan to give it credibility and prove buy-in. </span></span></span></span></span></p> <p><span><span><strong><span><span><span>Step five</span></span></span></strong><span><span><span> is creating an incident response plan. We often see plans that are light in nature, but the key is to ensure that the plans are realistic for your firm specifically and that your vendors and your customers that have a stake are accounted for. When creating an incident response plan, you want to involve internal parties like IT and HR as well as your external parties. The guiding light will be understanding what the impact on your customer base is. I think it's important to mention that you shouldn’t hesitate to talk to your vendors and see how they're going to respond to incidents that might came up. Incorporating an outside perspective from outside counsel is also very important as it can act as a due diligence of sorts on your own policies. The last point I'd like to make is that I think that having these conversations well ahead of time is critical because meeting your expectations of how the plan will impact how successful your response is requires proper planning in advance.</span></span></span></span></span></p> <p><span><span><strong><span><span><span>Step six</span></span></span></strong><span><span><span> is the planning, testing, training, and maintenance of your plan. Incorporating a tabletop exercises element is key so you can practice what is in the plan. Employee training sessions should be held annually but how you train - whether it's in person or remote sessions - is less important than the fact that you're covering your specific policies and procedures laid out by your firm. We often provide quick reference cards for employees so that they have information readily available when they walk out of a training session. An annual review of your BCP will help ensure that as things change, your plan changes, making it a living document. Keeping this as part of your culture is important to ensure that that the business continuity element is a foundation to your overall practice.</span></span></span></span></span></p> <p><span><span><strong><span><span><span>Matt Donahue:</span></span></span></strong><span><span><span> The final steps is <strong>step seven</strong>, communication. Communication is always something that can be improved upon, and that means how you communicate internally – not just from the management down, but truly how communication flows within your organisation - and externally, whether it be to the general public, whether it be to different regulators, whether it be to investors or vendors or third parties. You need to make sure that the appropriate communications are approved so that people are not just answering questions based upon their best knowledge. These are the areas where people can get in trouble, and consequently reputational and PR issues can arise. Make sure that you have a strong communications plan that is well practiced based on different situations, both internally and externally with your vendors.</span></span></span></span></span></p> <p><span><span><span><span><span>**********</span></span></span></span></span></p> <p><span><span><em><span><span><span><strong>Matt Donahue</strong> and <strong>Steve Banda</strong> were talking to <strong>Olivia Munro</strong>, Senior Marketing Specialist, <a href="https://www.eci.com/"><strong>Eze Castle Integration</strong></a></span></span></span></em></span></span></p> <p>***</p> <p><em>The views expressed in this article are those of the author and do not necessarily reflect the views of AlphaWeek or its publisher, <a href="https://thesortinogroup.com/">The Sortino Group</a></em></p></div> <!-- END OUTPUT from 'themes/gavias_vinor/templates/fields/field.html.twig' --> <!-- THEME DEBUG --> <!-- THEME HOOK: 'field' --> <!-- FILE NAME SUGGESTIONS: * field--node--field-tags--features.html.twig * field--node--field-tags.html.twig * field--node--features.html.twig * field--field-tags.html.twig * field--entity-reference.html.twig x field.html.twig --> <!-- BEGIN OUTPUT from 'themes/gavias_vinor/templates/fields/field.html.twig' --> <div class="field field--name-field-tags field--type-entity-reference field--label-hidden field__items"> <div class="field__item"><a href="/hedge-funds-guest-articles" hreflang="en">Hedge Funds Guest Articles</a></div> </div> <!-- END OUTPUT from 'themes/gavias_vinor/templates/fields/field.html.twig' --> <drupal-render-placeholder callback="flag.link_builder:build" arguments="0=node&amp;1=1822&amp;2=bookmark" token="VH0mNyjoPzI0UMHO_N_uIPz7eGvhvRVbT9RAzBb7WhY"></drupal-render-placeholder> <!-- THEME DEBUG --> <!-- THEME HOOK: 'field' --> <!-- FILE NAME SUGGESTIONS: * field--node--field-author--features.html.twig * field--node--field-author.html.twig * field--node--features.html.twig x field--field-author.html.twig * field--entity-reference.html.twig * field.html.twig --> <!-- BEGIN OUTPUT from 'themes/gavias_vinor/templates/fields/field--field-author.html.twig' --> <a href="/author/eze-castle-integration" hreflang="en">Eze Castle Integration</a> <!-- END OUTPUT from 'themes/gavias_vinor/templates/fields/field--field-author.html.twig' --> <!-- THEME DEBUG --> <!-- THEME HOOK: 'field' --> <!-- FILE NAME SUGGESTIONS: * field--node--field-content-role--features.html.twig * field--node--field-content-role.html.twig * field--node--features.html.twig * field--field-content-role.html.twig * field--list-string.html.twig x field.html.twig --> <!-- BEGIN OUTPUT from 'themes/gavias_vinor/templates/fields/field.html.twig' --> <div class="field field--name-field-content-role field--type-list-string field--label-above"> <div class="field__label">Content role</div> <div class="field__item">Public</div> </div> <!-- END OUTPUT from 'themes/gavias_vinor/templates/fields/field.html.twig' --> Fri, 30 Nov 2018 08:58:16 +0000 AlphaWeek Staff 1822 at https://alpha-week.com Cybersecurity Incident Response Management: Before, During and After https://alpha-week.com/cybersecurity-incident-response-management-during-and-after <!-- THEME DEBUG --> <!-- THEME HOOK: 'field' --> <!-- FILE NAME SUGGESTIONS: * field--node--title--features.html.twig x field--node--title.html.twig * field--node--features.html.twig * field--title.html.twig * field--string.html.twig * field.html.twig --> <!-- BEGIN OUTPUT from 'core/modules/node/templates/field--node--title.html.twig' --> <span>Cybersecurity Incident Response Management: Before, During and After</span> <!-- END OUTPUT from 'core/modules/node/templates/field--node--title.html.twig' --> <!-- THEME DEBUG --> <!-- THEME HOOK: 'field' --> <!-- FILE NAME SUGGESTIONS: * field--node--created--features.html.twig x field--node--created.html.twig * field--node--features.html.twig * field--created.html.twig * field--created.html.twig * field.html.twig --> <!-- BEGIN OUTPUT from 'core/modules/node/templates/field--node--created.html.twig' --> <span>Fri, 11/16/2018 - 10:45</span> <!-- END OUTPUT from 'core/modules/node/templates/field--node--created.html.twig' --> <!-- THEME DEBUG --> <!-- THEME HOOK: 'field' --> <!-- FILE NAME SUGGESTIONS: * field--node--body--features.html.twig * field--node--body.html.twig * field--node--features.html.twig * field--body.html.twig * field--text-with-summary.html.twig x field.html.twig --> <!-- BEGIN OUTPUT from 'themes/gavias_vinor/templates/fields/field.html.twig' --> <div class="field field--name-body field--type-text-with-summary field--label-hidden field__item"><p><span><span><span><span>Global IT provider, Eze Castle Integration, has been running an educational program for October’s ‘Cyber Security month’ and on Thursday, October 18th, hosted a webinar entitled ‘Cybersecurity Incident Response Management: Before, During and After’. AlphaWeek is publishing edited transcripts of these webinars. The speakers are Matt Donahue, <span>Business Continuity and Data Privacy Consultant, </span>and Jeremy Ross, Senior Product Manager, Eze Castle Integration, and the webinar was moderated by Olivia Munro, Senior Marketing Specialist, Eze Castle Integration. </span></span></span></span></p> <p><span><span><strong><span><span><span>The key terminology in cybersecurity incident response</span></span></span></strong></span></span></p> <p><span><span><strong><span><span><span>Jeremy Ross:</span></span></span></strong><span><span><span> A cybersecurity incident is defined by three things; the difference between an event, an incident, and a breach. An event is an observable occurrence in a system or a network; it can include a user connecting to a file share, a server receiving a request for a webpage, or a user sending an email and then a firewall blocking the connection attempt. An incident is a violation or an imminent threat of a violation to the computer security policy, like a security event that compromises the integrity, confidentiality, or availability of any information that you have. A breach is an incident that results in the confirmed exposure of data to an unauthorised party. The difference between something that is confirmed as being lost and being breached versus an incident that is something that may have compromised integrity is important to know.</span></span></span></span></span></p> <p><span><span><span><span><span>The National Institute of Standards of Technology produces an incident response life cycle. They put out standards and guidance for firms to follow, from incident response to business continuity and disaster recovery. It has four separate parts: preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. It's an ever evolving, continuous process that you need to be aware of. Incident response methodology typically emphasises preparation. Not only does this mean establishing incident response capabilities so that your organisation is ready to respond, but it also means working to prevent incidents to ensure that systems, networks, and applications are sufficiently secure.</span></span></span></span></span></p> <p><span><span><strong><span><span><span>Preparation</span></span></span></strong></span></span></p> <p><span><span><span><span><span>It's not if you'll be breached, it's when. This is a common saying within the cybersecurity industry; 58% of firms have experienced a compromise or breach in the past year, according to a Forrester Report.  Your key stakeholders, clients, and other observers expect you to take reasonable measures in the first place, but when that does inevitably fail, you want to be able to respond quickly and appropriately. Having an effective incident response management program is key and essential to that.</span></span></span></span></span></p> <p><span><span><span><span><span>Incident response is a complex undertaking. Establishing a successful incident response capability requires a lot of planning and resources that need to be aligned. Breaches happen, and so you're going to want to be able to have the capability to respond in the appropriate manner. In order to do that properly, you're going to need a team of dedicated individuals who will be able to respond. Along those lines, many organisations create what is called a computer incident response team, also known as a CIRT, which is a specialised group tasked with responding to these incidents. At its core, it’s a cross-functional team of internal and external experts tasked with responding to a breach, but they must also facilitate communication amongst themselves, notify regulatory agencies, and implement policies and procedures around incident response so that situations are handled according to best practices.</span></span></span></span></span></p> <p><span><span><span><span><span>Not every individual in the organisation is supposed to be or going to be on the incident response team. Additionally, you should always consider outside help. There are numerous external vendors and partners you can engage with, from handling all of incident response, or just breach notification, or legal. You should consider engaging those external partners, rather than just building them in-house.</span></span></span></span></span></p> <p><span><span><strong><span><span><span>Departments involved in the CIRT</span></span></span></strong></span></span></p> <p><span><span><span><span><span>IT: IT staff mainly consists of network administrators to help with investigations when you have an incident. They'll be key to find out who owns and manages the system, who has the furnished skills, and who has administrator access. Without IT, it would be impossible for your CIRT to gain access to the system.</span></span></span></span></span></p> <p><span><span><span><span><span>Corporate communications: You may want a key member from that department who is going to speak for the company and deliver the message the company wants to present to customers and business partners. During an incident this is key because you don't want multiple messages going out. You want one clear, single, unified message that's going to tell your key parties exactly what's going on in the incident.</span></span></span></span></span></p> <p><span><span><span><span><span>Legal: You need to know who to contact when investigations can show criminal activity. You may have to report to the appropriate regulatory bodies, however you're going to want to engage legal staff before that to provide guidance on the legality of potential breaches, and the requirements of evidence collection and breach notification.</span></span></span></span></span></p> <p><span><span><span><span><span>Information Security: You want involved those individuals who are responsible for handling the details of the investigation itself, for example looking at the logs, figuring out exactly what happened, and then digging deeper with a forensic analysis. That's where information security staff are going to play a bigger role. You might hire some consultants to deal with this aspect of it.</span></span></span></span></span></p> <p><span><span><span><span><span>Business representatives: Without having the line of business representative, it would be impossible to figure out how the incident impacts a specific product or product line. IT teams need to partner with the business unit data owners to understand the data implications if an incident did occur to that data. You want that to be done prior to an incident occurring.</span></span></span></span></span></p> <p><span><span><span><span><span>Still in the ‘preparation’ phase, we have data classification protection. This is a key part of incident response because if you don't know what you must protect and where it is then you can't properly protect it. At a base level, all firms need to protect PII, which is personally identifiable information, PHI, which is protected health information, and non-public information, also known as NPI.</span></span></span></span></span></p> <p><span><span><span><span><span>Knowing that, there are also some considerations for data protection, which is where the data resides. Is it in some random HR database? Is it in an Excel file online, in the cloud, is it just a file share on your network? Answering those questions and considering where it is allows you to understand what changes need to be made and aligned with best practices. You're going to know who has access to that data, but everyone shouldn't have access to all the data. If someone from finance or another department has access to a payroll database, for example, that may be a risk and you're going to want to investigate who has access to your critical databases. Having an asset inventory of your systems and networks gives you visibility, which is critical to incident response. By locating and knowing the critical assets that you or your firm simply can't lose – those that will put you in an end-game, out of business situation - then you will better position yourself to prepare and respond to the threats that you face.</span></span></span></span></span></p> <p><span><span><span><span><span>Finally, the importance of training and testing, at least on a biannual or annual basis, can’t be emphasised enough. Train employees on their roles and responsibilities during incident response. If an employee doesn't know their role and responsibility during an incident, they're going to be stuck in a tense, stressful situation without a clear action plan. If you develop plans, follow-up and train on those policies and plans, when an actual incident occurs, you're not going to have to overthink everything. You're just going to follow the prescriptive steps that are necessary in the plan, and work with the team to achieve your goal. When you develop plans based on the scenarios of specific events, make sure your team knows exactly how to respond in that situation. Therefore, they're going to know exactly how to walk through it because it has been simulated before. We always encourage a lot of table-top procedures and simulations throughout the year.</span></span></span></span></span></p> <p><span><span><strong><span><span><span>Detection and analysis</span></span></span></strong></span></span><span><span>        </span></span></p> <p><span><span><span><span><span>During the detection phase we see identification from various sources. Some of these things can be internal alerts that will show you the data. These are like trip wires; alerts will notify you that there is some discrepancy. You might get something externally from vendors, you might receive something from information sharing networks, you might get an email from the FBI saying there is malicious activities.</span></span></span></span></span></p> <p><span><span><strong><span><span><span>Matt Donahue: </span></span></span></strong><span><span><span>If there is malicious activity coming out, IP's in your domain. There's a lot of different ways that these things can come in, but once you detect it and you can do initial analysis, then you need to figure out how you're going respond to this. Typically, better practices lie in having a core group of people that can take that initial information and size it correctly. It's not all about getting everybody on the phone, or bringing everybody in the room, because that can take a lot of time. You want to have a core group of people that are trained to get the message out and get the process going.</span></span></span></span></span></p> <p><span><span><span><span><span>You're going to want to call in your subject matter experts, whether that be internal staff or third parties that you might have that are going to assist you in various ways; cyber security specialists, incident specialists, general counsel, outside council. Bring the people in based on the planning that you've done.</span></span></span></span></span></p> <p><span><span><span><span><span>In the ‘boom’ phase, that's what you're doing. Early on, a lot of people get confused. You want to stick to the plan. There are certain times when delineations are necessary but for any type of delineation, I would always recommend documenting those and showing the reasoning to why you would do so. Any delineation from the plan could be looked at negatively by insurers or regulators unless you have good reason to do so. Make sure that you stick to the plan as much as you can.</span></span></span></span></span></p> <p><span><span><span><span><span>Once you know that there's a breach you want to communicate internally as well as externally to make sure that there's a consistent message being spread. You want to be proactively giving messages, or keeping a consistent type of message, so that all parties are made aware of what the situation is, or that you'll be giving them updates on some type of cadence that they're going to be familiar with. They'll then be looking for it, minimising the risk of letting them invent their own messaging.</span></span></span></span></span></p> <p><span><span><strong><span><span><span>Containment, eradication and discovery</span></span></span></strong></span></span></p> <p><span><span><span><span><span>There are various options for containment; you quarantine the breach, you are segregating it, shutting it down. Exactly what you do is going to be based upon your knowledge of what that resource is and what the impact of doing certain things are. You're only going to do that by better understanding the various plans you're going to plug into.</span></span></span></span></span></p> <p><span><span><span><span><span>What would help you to make that decision would be to refer to your continuity plan. If you need that resource to continue running, quarantine it. If it’s not business critical, shut it down. If it's not going to have a major impact, take it offline, fix it or restore it, and bring it back. Or maybe your issue is within tolerable levels. Deciding what is okay and what isn't okay, in terms of tolerance, can only be done if you know what you have and how critical it is to your business and business processes. </span></span></span></span></span></p> <p><span><span><span><span><span>In terms of eradication, you're going to be gathering the evidence but you're also going to be removing things. Make sure that there are going to be no additional problems, and that anything that's had an impact, for example malware, is going to be removed, because you want to have your system clean. </span></span></span></span></span></p> <p><span><span><strong><span><span><span>Recovery</span></span></span></strong></span></span></p> <p><span><span><span><span><span>The last phase would be recovery. When you have all these different types of systems or assets, they're going to be brought back online into their normal operating procedure, or at least, at acceptable levels. Analysing what is acceptable and what isn't indicates that you're in the recovery phase. Critically, none of this can happen until you completed the previous two phases. </span></span></span></span></span></p> <p><span><span><strong><span><span><span>How the different types of plans work together</span></span></span></strong></span></span></p> <p><span><span><strong><span><span><span>Matt Donahue:</span></span></span></strong><span><span><span> In terms of the various types of plans, we first have your written information security plan. It documents what you currently have for your information security systems and the various controls; what's critical and what's not in terms of security. It might encompass an incident response, it might not, but it takes that lens of security and builds up what's currently going on in your infrastructure, what's important, and where should people be looking at in terms of incidence. Let's say a drive X has different types of customer data, but drive Y has the marketing materials. If X goes down, that's a problem with Y. Knowing some of those specifics is helpful, and that's some of the information you want to put in that information security plan.</span></span></span></span></span></p> <p><span><span><span><span><span>As discussed, disaster recovery plans address issues from a technical standpoint. Something's going down, something's not working, so it’s having that ability to get back into regular business types of operations at a regular time.</span></span></span></span></span></p> <p><span><span><span><span><span>Business continuity plans focus on criticality; if this is the system that's impacted by this type of cyber threat, how critical is this to our business? Without doing that type of analysis, or that investigation that you would do during a business continuity plan, that information might not be known. It's important to be able to have some of these different things done, as they do touch.</span></span></span></span></span></p> <p><span><span><span><span><span>We've been talking about incident response so depending upon what the incident might be, you're probably going to look at most, if not all, of these plans during that incident response planning. Let's say there's an incident going on right now and you're not sure what it is. First, identify what the issues are, and then you can look at the business continuity plan and the written information security plan to say, ‘all right, based on this, this is critical’. You figure out what the problem might be and how it impacts your business. These plans all work together to inform each other, as well as helping to evaluate what your options might be. </span></span></span></span></span></p> <p><span><span><strong><span><span><span>Matt Donahue:</span></span></span></strong><span><span><span> The final step is the post activity types of things. Once everything is close to resumption of normal activities, you might want to look at some external assistance, as we mentioned earlier. If there's going to be an impact, or if you're going to be doing something in terms of using your insurance to help pay for some of the costs that have been associated with this disaster, some of the teams that you have identified might be pulled in. A lot can be paid for through insurance, but you want to make sure everything's documented. You want to do some forensic analysis, so you can show that you did what you could, but this is what the issue was.</span></span></span></span></span></p> <p><span><span><span><span><span>If there's a potential regulatory impact, again, you're going to want to have that proof of investigation, you're going to want to have those digital forensics to make sure you did what you were supposed to do, you followed along with your best practices and didn't delineate from your plans. Or, on the legal side, if people are going to be potentially filing investigation work, it's good to have evidence, especially if it's the kind of incident where there's going to be a lot of eyes on your company as your firm. External counsel and independent search teams can come in and help support you within this process. Again, this is a nuanced type of activity that not a lot of people can necessarily be masters of, or experts, when they're doing a lot of other things from a typical business standpoint.</span></span></span></span></span></p> <p><span><span><span><span><span>Another important thing to do is to have a postmortem. It's going to show you where there were areas for opportunity, things that went well, and things that were modified or potentially could change down the road. A lot of times the value of going to that ‘lessons learned’ discussion is that you can take things that went well, or that didn't work well, and reapply that to the preparation state. You can then modify your plans, add new or different caveats, put in things that will be helpful for the next time. That's an important part of the process.</span></span></span></span></span></p> <p><span><span><strong><span><span><span>Real life examples of cyber security incidents</span></span></span></strong></span></span></p> <p><span><span><strong><span><span><span>Matt Donahue:</span></span></span></strong><span><span><span> Using ransomware for example, users are going to have something pop up on their screen. Someone's going to have to forward something, whether to IT, to the help desk, or whoever it might be in the CIRT. Notification should be an efficient process, but it must also ensure that the notification is going to involve the right people.</span></span></span></span></span></p> <p><span><span><span><span><span>Then you're going to want to get the playbook out. Get specifics of the scenario that you think is happening. In this instance it is clearly a ransomware, so go to that specific type of cue card. Analyse what the issue is and then get specific.</span></span></span></span></span></p> <p><span><span><span><span><span>When you do get specific, you want to look to say, ‘okay, now we know that it's a ransomware situation. Who else needs to join in this conversation?’ and then get them involved. Then follow the steps. Everybody knows what they should be doing and what they should be concerned about because it's almost like everybody has their own role to play here. This specifically is a case of ransomware and what you really need to do is isolate it to limit its spread. Look at logs to see what people have, look at what was the potential way that it was delivered, and seeing what you do to minimise that, isolate it, segregate it, and keep it from continuing to spread.</span></span></span></span></span></p> <p><span><span><span><span><span>Once that's done, you're going to want to look at some of the plans that we have discussed. A lot of times, with ransomware, you're going to want either restore it through a disaster recovery process or do some type of resumption through your regular types of continuity procedures. You can't shut down everything, but you must know what the impact was, what you had to do to handle it and how you can recover and respond. So bringing back those two plans can help you figure out, especially with ransomware, what you can potentially do right now.</span></span></span></span></span></p> <p><span><span><span><span><span>With ransomware, don't be afraid to bring in outside assistance. Sometimes you can save a lot of money by being able to take care of it yourself but at the end of the day, what the hackers are going to say is ‘we have X amount of information that we have encrypted, and we're going to destroy it if you don't pay us X amount of money’, so are you really going to try remediate this yourself, or are you going to pay, or maybe a little bit of both? Either way, you’re paying for it. If you're going to pay, it's usually cryptocurrency, so if that's ever going to be in the realm of how you're going to respond to ransomware, it might be good to have that set up initially because it's not always an easy thing to have those resources already prepped. Many people say that you shouldn’t pay ransomware, but that's really going to be up to you to decide at the time. If it's only a little bit of money, or, based on the value of the asset at the time that or what the destruction of the data is going to cost, maybe it's sometimes worth doing it.</span></span></span></span></span></p> <p><span><span><span><span><span>There are a lot of decisions that must be made. As you can see here, this is a high-level summary of an incident, but how a lot of these different steps come together will help you out. And then, at the end of the day, it comes to the decisions which must be made, specifically for a ransomware scenario because it's usually a timetable versus an infection. But you can see here how a lot of these things come together, and so the pre-planning work that you can do ahead of time will help.</span></span></span></span></span></p> <p><span><span><strong><span><span><span>Jeremy Ross: </span></span></span></strong><span><span><span>The second sample incident we're going to cover is a phishing email. Phishing or spear phishing attacks are very common. Let's say IT is alerted to an event where an employee entered credentials into what looked like a platform typically used for work, and then the employee became suspicious as the link, which was spoofed and sent from what looked like a colleague's email, brought them to a portal which was a strange landing page.</span></span></span></span></span></p> <p><span><span><span><span><span>First, you're going to want to determine the potential extent of the issue. If they're targeting or attacking one portal, you're going to want to keep a close eye on that portal and start with re-setting the account access and passwords for those users. The next step would be to run scans and pull logs to determine if there's any further impact. If there are any lateral or horizontal moves being done by the attacker, you want to see them. Visibility into your network is key; that preparation and understanding of what you have is going to really help when you get an incident like this that could bloom into something bigger. So seeing those moves, running those scans and logs when you need them is going to be very critical.</span></span></span></span></span></p> <p><span><span><span><span><span>Also, make this is a learning lesson. For phishing, you're going to want to know exactly how to report suspicious emails. That's a very key thing that people don't do enough of in my experience. It's good to report, because by reporting, you're helping to protect others in your firm. IT is going to log it and make sure that other people will have it blocked in their inboxes, thereby eliminating the risk of anyone clicking on it or downloading any images or malware. The second part of making it a learning lesson is learning phishing framing simulations to identify phishing emails. When you start to identify two or three phishing emails you greatly reduce the risk of you actually clicking on the legitimate attack phishing email by more than 70 percent. Running a phishing training simulation with your employees is a great way to reduce the likelihood of a phishing email impacting your firm. Often it only takes one weak link, and this type of incident can be a bad one to have to go through if you let it go too far.</span></span></span></span></span></p> <p><span><span><span><span><span>Lastly, there are a few technical things you should do like updating email filters and checking your other logs, such as a mail server, your firewall or proxy servers, or even your sim, for any other indicators of intrusions or attacks surrounding the phishing email that was initially received.</span></span></span></span></span></p> <p><span><span><strong><span><span><span>Final thoughts</span></span></span></strong></span></span></p> <p><span><span><strong><span><span><span>Matt Donahue:</span></span></span></strong><span><span><span> At a high level, we've been emphasising throughout this discussion the importance of getting the right people together. That might be internal, that might be external, but just start the discussion. Start to talk about how you are going to handle this, and then go through the different scenarios. But make it specific; certain industries only have various types of threats, or the threats they do face are more prevalent. Know what those are and use that as your template. If you can make it a living and breathing thing that has a lot of people working together, you're going to be more successful, because everybody's going to buy in.</span></span></span></span></span></p> <p><span><span><span><span><span>In terms of planning smarter, it's good to bring people in to go through that. Not all this stuff can be solved internally, and you don’t have to spend millions of dollars to do it. Look at what the important things within your environment are and then you can make better decisions. Another thing a lot of people miss the ball on is the metrics that matter for a lot of these decisions. Review what you're spending or what you currently have in place for things like preventative measures. What are the controls that you currently have? Do you have everything that you need to? If not, then perhaps you need only patch a couple of holes versus trying to swallow a huge pill that might be hard for your organisation. Look at the risks specific to your size, your complexity, the industry that you're in, your location, the employees that you have. Look at your liabilities from a legal and contractual standpoint. Look to see what the worst-case scenario would be. That way you can hyper focus on what's important to protect and what you should be putting in place to defend it.</span></span></span></span></span></p> <p><span><span><span><span><span>On the reputational side, if there is an incident at your firm, how is that going to represent your reputation internally to employees and externally to investors? Consider how you want to see your reputation in the public eye.</span></span></span></span></span></p> <p><span><span><span><span><span>Finally, test and train. That's critical to the success of your program, as well as your response. Make sure people are aware of what their responsibilities are and go through a test. This is one of the things we really want people to walk away with; get to those next steps where you are doing the testing and training and get the right people in to discuss this properly.</span></span></span></span></span></p> <p><span><span><span><span><span>**********</span></span></span></span></span></p> <p><em><span><span><span><span><span><strong>Matt Donahue</strong> and <strong>Jeremy Ross</strong> were talking to <strong>Oliva Munro</strong>, Senior Marketing Specialist, <a href="https://www.eci.com/"><strong>Eze Castle Integration</strong></a>.</span></span></span></span></span></em></p> <p>***</p> <p><em>The views expressed in this article are those of the author and do not necessarily reflect the views of AlphaWeek or its publisher, <a href="https://thesortinogroup.com/">The Sortino Group</a></em></p></div> <!-- END OUTPUT from 'themes/gavias_vinor/templates/fields/field.html.twig' --> <!-- THEME DEBUG --> <!-- THEME HOOK: 'field' --> <!-- FILE NAME SUGGESTIONS: * field--node--field-tags--features.html.twig * field--node--field-tags.html.twig * field--node--features.html.twig * field--field-tags.html.twig * field--entity-reference.html.twig x field.html.twig --> <!-- BEGIN OUTPUT from 'themes/gavias_vinor/templates/fields/field.html.twig' --> <div class="field field--name-field-tags field--type-entity-reference field--label-hidden field__items"> <div class="field__item"><a href="/hedge-funds-guest-articles" hreflang="en">Hedge Funds Guest Articles</a></div> </div> <!-- END OUTPUT from 'themes/gavias_vinor/templates/fields/field.html.twig' --> <drupal-render-placeholder callback="flag.link_builder:build" arguments="0=node&amp;1=1794&amp;2=bookmark" token="J7ge7TjlmKicUUM9PX5dcoQzjr4Akx4OkveJoU8Nt34"></drupal-render-placeholder> <!-- THEME DEBUG --> <!-- THEME HOOK: 'field' --> <!-- FILE NAME SUGGESTIONS: * field--node--field-author--features.html.twig * field--node--field-author.html.twig * field--node--features.html.twig x field--field-author.html.twig * field--entity-reference.html.twig * field.html.twig --> <!-- BEGIN OUTPUT from 'themes/gavias_vinor/templates/fields/field--field-author.html.twig' --> <a href="/author/eze-castle-integration" hreflang="en">Eze Castle Integration</a> <!-- END OUTPUT from 'themes/gavias_vinor/templates/fields/field--field-author.html.twig' --> <!-- THEME DEBUG --> <!-- THEME HOOK: 'field' --> <!-- FILE NAME SUGGESTIONS: * field--node--field-content-role--features.html.twig * field--node--field-content-role.html.twig * field--node--features.html.twig * field--field-content-role.html.twig * field--list-string.html.twig x field.html.twig --> <!-- BEGIN OUTPUT from 'themes/gavias_vinor/templates/fields/field.html.twig' --> <div class="field field--name-field-content-role field--type-list-string field--label-above"> <div class="field__label">Content role</div> <div class="field__item">Public</div> </div> <!-- END OUTPUT from 'themes/gavias_vinor/templates/fields/field.html.twig' --> Fri, 16 Nov 2018 10:45:57 +0000 AlphaWeek Staff 1794 at https://alpha-week.com Addressing Common IT Gaps For Investment Management Firms https://alpha-week.com/addressing-common-it-gaps-investment-management-firms <!-- THEME DEBUG --> <!-- THEME HOOK: 'field' --> <!-- FILE NAME SUGGESTIONS: * field--node--title--features.html.twig x field--node--title.html.twig * field--node--features.html.twig * field--title.html.twig * field--string.html.twig * field.html.twig --> <!-- BEGIN OUTPUT from 'core/modules/node/templates/field--node--title.html.twig' --> <span>Addressing Common IT Gaps For Investment Management Firms</span> <!-- END OUTPUT from 'core/modules/node/templates/field--node--title.html.twig' --> <!-- THEME DEBUG --> <!-- THEME HOOK: 'field' --> <!-- FILE NAME SUGGESTIONS: * field--node--created--features.html.twig x field--node--created.html.twig * field--node--features.html.twig * field--created.html.twig * field--created.html.twig * field.html.twig --> <!-- BEGIN OUTPUT from 'core/modules/node/templates/field--node--created.html.twig' --> <span>Wed, 11/07/2018 - 15:03</span> <!-- END OUTPUT from 'core/modules/node/templates/field--node--created.html.twig' --> <!-- THEME DEBUG --> <!-- THEME HOOK: 'field' --> <!-- FILE NAME SUGGESTIONS: * field--node--body--features.html.twig * field--node--body.html.twig * field--node--features.html.twig * field--body.html.twig * field--text-with-summary.html.twig x field.html.twig --> <!-- BEGIN OUTPUT from 'themes/gavias_vinor/templates/fields/field.html.twig' --> <div class="field field--name-body field--type-text-with-summary field--label-hidden field__item"><p><span><span><span><span><span><span>Global IT provider, Eze Castle Integration, has been running an educational program for October’s ‘Cyber Security month’ and on Thursday, October 11th, hosted a webinar entitled ‘Addressing Common IT Gaps for Investment Management Firms’. AlphaWeek is publishing edited transcripts of these webinars. The speakers are Alex Beher, Director, NY Service, Eze Castle Integration, and Mike Pappacena, Partner, ACA Aponix, moderated by Mary Beth Hamilton, Vice President, Marketing at Eze Castle Integration.</span></span></span></span></span></span></p> <p><span><span><strong><span><span><span>The risk assessment process and how that works for financial firms</span></span></span></strong></span></span></p> <p><span><span><strong><span><span><span>Mike Pappacena:</span></span></span></strong><span><span><span> One thing that's been really a key focus of regulators, specifically the SEC and for those firms that are NFA registered is to have a rigorous cyber security program in place with advisors. And part of that is conducting periodic risk assessments. That can be conducted either internally by qualified folks or through a third party where a team would come in. </span></span></span></span></span></p> <p><span><span><span><span><span>Based on common frameworks, such as NIST, they would perform a review on cyber security and technology risk controls, for example, access controls, data governance, data loss, physical security and resiliency, and look to paint a wholistic risk profile of a firm. One key thing that's important in a risk assessment is to really dig deep and understand nuances about the firm and the type of business that they're in. For example, when you're looking at registered investor advisors, whether it's across a hedge fund, private equity fund, etc., focusing on how investor data is protected and how that information flows through a firm's ecosystem is important.</span></span></span></span></span></p> <p><span><span><span><span><span>When we look at firms in terms of governance, we do see obviously a focus on regulatory compliance. In some cases we see firms addressing operational risk but not necessarily looking at their cyber security and technology risks. The first step as part of that governance is including cyber security and technology risk with respect to the other risks that you look at as a firm. In many cases, that responsibility falls largely on compliance officer. In some cases, there's a chief technology officer that works alongside the COO. If the firm is large enough, they may elect to dedicate someone from a cyber security standpoint and have a chief information security officer. Smaller firms may not necessarily have those resources.</span></span></span></span></span></p> <p><span><span><strong><span><span><span>How are smaller firms that may not have dedicated internal resources are handling this?</span></span></span></strong></span></span></p> <p><span><span><strong><span><span><span>Alex Beher:</span></span></span></strong><span><span><span> Today, even the smaller firms think about cyber security seriously and not looking at it as an IT department function. More than ever, it takes a mix of internal people taking responsibility for regulation policy. But it also requires help from outside, like third party consultants, third party vendors. And whilst larger firms tend to focus on employing their own IT and internal security teams, the smaller firms tend to rely more on third party consultants and vendors to fill in this gap. These days, it’s a full-time job to stay on top of all the information and policies and new regulations that are coming from various governing bodies, whether it's the European Union, United States, or a specific state where the company may have an office. And that's why those smaller firms need to rely on a third-party consultant because it's very easy to get lost with the huge, unending amounts of data. Firms trying to stay ahead of the curve want to make sure they meet the regulations that they're subject to and stay up to date. It's often very difficult to know what information is applicable to them and what isn’t. That's when the turn to the third parties to consult them on this and to fill in the gap that they can't do internally.</span></span></span></span></span></p> <p><span><span><strong><span><span><span>Mike Pappacena:</span></span></span></strong><span><span><span> I think that what firms are starting to realize is that cyber security is not just about technology, it's also about the operation and the risk management piece. And that's crucial for firms to think about when they put their governance program in place.</span></span></span></span></span></p> <p><span><span><strong><span><span><span>IT asset management: holes to plug</span></span></span></strong></span></span></p> <p><span><span><strong><span><span><span>Mike Pappacena:</span></span></span></strong><span><span><span> It’s key to understand what assets a firm has. An asset can mean many different things. It's important for firms to really understand what their inventory is from a hardware standpoint, like servers that they're using, work stations, laptops, mobile devices. All these different devices are an access point to a firm's information, and it's important that firms have an inventory of that.</span></span></span></span></span></p> <p><span><span><span><span><span>On the software side, what are the systems and applications that firms are using? You have trading systems, which could be deployed either on-premises or externally. You have customer client relationship management software and accounting software, and you have other third parties that provide information and exchange information through portals, like a fund administrator. When you start thinking about where those assets are, you could very easily see that it's not just about what a firm has or "owns"; but also software as a service and third-party services. What you're using that's externally hosted is something that you should inventory. As you start thinking about where data is and who has access to what resources, understanding your software as a service is extremely important. As more firms move more and more of their services off-prem and into the cloud, the importance becomes higher.</span></span></span></span></span></p> <p><span><span><strong><span><span><span>Best practices in classifying data and permissioning access</span></span></span></strong></span></span></p> <p><span><span><strong><span><span><span>Alex Beher:</span></span></span></strong><span><span><span> There are tools available that can scan your data and help classify it; they usually have a database of pre-defined sets of rules that can be checked against your data and then put the different sets of data in the data packets to help you understand really what data that you have. These tools allow you to customize those rules as well to help you specifically build them around the needs of the firm.</span></span></span></span></span></p> <p><span><span><span><span><span>We recommend conducting an annual review cycle of all IT assets to fully understand if there have been addition or deletion changes, and how the technology is managing that data and what controls are in place to protect it. We see a lot of firms leverage user provision and identity management software to facilitate the process of provisioning and managing new user access, but we also see firms still doing things the old fashion way. This can be effective for a lot of firms if they and their IT administrator understand and employ the ‘principle of least privilege’. </span></span></span></span></span></p> <p><span><span><span><span><span>The principle of least privilege states that the access for the user should be limited and based strictly on whether they need it. Employees who are staff need only have access to the system and data that allow them to do their job. Any additional level of access or additional exposure to data that they don't need for their job should be removed.</span></span></span></span></span></p> <p><span><span><strong><span><span><span>Vulnerability assessment</span></span></span></strong></span></span></p> <p><span><span><strong><span><span><span>Alex Beher:</span></span></span></strong><span><span><span> A vulnerability assessment scans the environment and network to determine areas of vulnerability and create a database of known risks. Vulnerabilities are often classified based on severity and you get a report that lists all of the found vulnerabilities, the severity of their risks, and difficulty to remedy. With the penetration test on the other hand, it's vulnerability assessment with tools and people behind it. Using a testing tool, it simulates real world attack scenarios and determines if the hacker would be able to gain entrance into the firm's network using those vulnerabilities. When we talk about vulnerability assessments with our clients, given all the off the shelf products and solutions that they have, we recommend having the vulnerability assessment running regularly as a healthy way to protect them from new vulnerabilities. When the VA runs, and you find new vulnerabilities you then raise this with software vendor.</span></span></span></span></span></p> <p><span><span><span><span><span>A penetration test is usually more applicable when you have custom developed software that you need to ensure is properly secure, whether that’s your external patient website, your externally accessed portal or remote access to your environment; systems where you need to ensure that your system is securely protected and can't be penetrated. </span></span></span></span></span></p> <p><span><span><span><span><span>It's specifically very relevant with your internet patient site. Here at EzeCastle we have our customer portal that has been custom developed for us, so we've delivered several projects to the penetration test to make sure that it's secure and hardened to protect our customer's data.</span></span></span></span></span></p> <p><span><span><span><span><span>It's a good a practice to have vulnerability assessment done regularly to keep on top of recently identified vulnerabilities. There are several different vendors; ACA being one of the common ones that many of our clients use. I think the key to VAs and pen tests are taking a risk-based approach. Firms need to identify the key risk during the risk assessment process and then use those identified risks to tailor their approach to a vulnerability assessment.</span></span></span></span></span></p> <p><span><span><strong><span><span><span>Frequency of vulnerability assessments and common gaps</span></span></span></strong></span></span></p> <p><span><span><strong><span><span><span>Mike Pappacena:</span></span></span></strong><span><span><span> Often, when we visit a new client, we're doing the first vulnerability assessment that they have gone through. At a minimum we would want to see vulnerability scans being conducted on an annual basis. The vulnerability assessments provide a good view of everything that's on your network and can highlight where there are potential gaps, breaks and items that need to be addressed. </span></span></span></span></span></p> <p><span><span><span><span><span>Something that you might find is devices that are unpatched. If you see that on a vulnerability assessment, it's not just about patching the device; it's more about figuring out why these devices aren't patched to begin with and reviewing your patch management process, so the next vulnerability scan won’t reveal so many concerns.</span></span></span></span></span></p> <p><span><span><span><span><span>It's important to really understand the difference between vulnerability assessments and penetration testing. The vulnerability scans will just tell you where you have potential exposure; where a pen test will look to see what's open and try to access. A pen test is something that firms should consider doing annually every-other year. </span></span></span></span></span></p> <p><span><span><strong><span><span><span>What risk elements should be incorporated into a vulnerability assessment?</span></span></span></strong></span></span></p> <p><span><span><strong><span><span><span>Mike Pappacena:</span></span></span></strong><span><span><span> Taking risk-based approach means looking at what assets I have and where I want to look for vulnerabilities. When we talk about a risk-based approach to pen testing, there are different ways to pen test and different things that can be pen tested. This has to do with thinking about your biggest risks. Someone forcing their way in externally through a firewall is far more unlikely than a bad actor getting access to the premises and being able to plug a device into your network. You need to look at the most likely scenarios for something to happen, and then targeting your testing around that. It’s different for each firm.</span></span></span></span></span></p> <p><span><span><strong><span><span><span>Patch management process and strategies</span></span></span></strong></span></span></p> <p><span><span><strong><span><span><span>Alex Beher:</span></span></span></strong><span><span><span> Patch management is one of the important defence mechanisms that can protect your organization from cyber-attacks and hacking. It's also becoming a top tier question on investor due diligence that we see with our clients; the investor looks for insurance that comes with firms staying current with software system upgrades. It's imperative that the firm has a solid and robust patch management program.</span></span></span></span></span></p> <p><span><span><span><span><span>Patching is like a vaccination; you use a vaccination to prevent yourself from getting a virus. Patching prevents computers from being vulnerable to viruses. So when a virus emerges, or somebody develops a specific virus to hack the computer's operating system or applications, the operating application will need to develop a new patch.</span></span></span></span></span></p> <p><span><span><span><span><span>With that in mind, patching will only be effective when it's done on a regular basis. It also needs to be properly managed to ensure those patches are properly tested and verified. People often forget about testing patches, but it's an important part of any patch management program; with every new patch there is the likelihood of compatibility issues with the application. Often, when the vendor develops a patch, they don't have capacity to test it with every single application out there, so if the firm has a lot of different applications, it's important that that patch is tested in their UET or development environment before it is rolled out in production, as this helps minimise the necessary down time.</span></span></span></span></span></p> <p><span><span><span><span><span>Given the huge number of patches and different software solutions that need to have patches developed for them, it's important that there is a process to track all those patches. Usually, it needs to be as automated because it's incredibly difficult to do it manually. At EzeCastle, we have a patch program called EzePatch Management, which includes all of these points and automation to identify the approval process for patches that need to be deployed, as well as the testing program for those patches to be rolled out to production.</span></span></span></span></span></p> <p><span><span><strong><span><span><span>Frequent gaps identified in patch management</span></span></span></strong></span></span></p> <p><span><span><strong><span><span><span>Mike Pappacena:</span></span></span></strong><span><span><span> Often what we see of out in the field with clients is no formal cadence to patching; no real vetting of patches before they’re deployed. A lot of times we see patching not automated, done manually, with a lack of validation that the patches have worked. </span></span></span></span></span></p> <p><span><span><span><span><span>One of the key things that we see are devices where patches fail. Perhaps you have a mobile device like a laptop that's not connected to the network; outside of the auto update you wind up with machines that are lagging behind so it’s crucial to put in place monitoring of all devices, and put some sort of preventative controls in place, like enforcing that patches are updated if a laptop is off the network for a period of time before it can connect back in.</span></span></span></span></span></p> <p><span><span><span><span><span>If critical patches fail on a deployment, you need a process to say within 24 to 48 hours you address the critical patches. If patches are less critical you can wait until the next patching cycle, but putting in place a process for critical patches is key. When you talk about evidencing this to a regulator or ODD team the reports are good but you need to show that you have a program. </span></span></span></span></span></p> <p><span><span><span><span><span>The other thing we see as a frequent gap is that most of the time folks are just talking about Windows and/or operating system patches. Third party patches are also really important. You have to make sure that you are patching your third-party programs. A lot of time, patching programs don't necessarily address non-operating system or non-Windows, and firms need to really understand that if they have important software that's used by everyone, whether it's a Java plug-in or a third-party pdf reader, that you are updating those as well.</span></span></span></span></span></p> <p><span><span><span><span><span>You also need to ensure that your infrastructure provider or your internal technology team are patching non-Windows machines. If you've got other operating systems, appliances, voice systems, have a process in place to make sure that they're kept up to date and patched as well. You don't want to forget about all the other devices that are connected to your network. Whoever's responsible for managing those devices should be patching those as required by the vendor, with at least an annual review to make sure that there's nothing out there that needs to be addressed.</span></span></span></span></span></p> <p><span><span><strong><span><span><span>Phishing scams and other types of targeted emails, schemes, or attacks</span></span></span></strong></span></span></p> <p><span><span><strong><span><span><span>Alex Beher:</span></span></span></strong><span><span><span> The ultimate goal of social engineering is to trick the end user to divulge information, whether it's credentials or personal financial information or company financial information. These attacks are getting more and more sophisticated every year. There is a lot of information out there about the company or person that is easily available over the internet to anyone, which makes it easier for any attacker to target a specific individual because they know enough about the person and their role in the company to easily craft an email that would appear to be coming from somebody that the person knows or somebody who is knowledgeable about the organization or the structure.</span></span></span></span></span></p> <p><span><span><span><span><span>The key to thwart social engineering is not an expensive piece of technology but rather a commitment to user education and user training. Firms should have mandatory and frequent training to remind them of cyber security risk and the consequences of our latent security policies. Employees should understand the risk of taking devices that contain confidential data out of the secure work spaces and they should understand what happens when the device gets stolen from their cars or homes. How do they dispose of those devices and remove the data from them properly? All this needs to be part of the education and training program and the culture in the company needs to be built with cyber security in mind. We always recommend to our clients that they have an effective training program and the most effective way we see to prevent phishing attacks is to train employees. </span></span></span></span></span></p> <p><span><span><span><span><span>On top of user training, there are also tools that help you to protect your firm from phishing attacks. Some of the next generation consoles that we see these days have an AI component built in that helps identify certain patterns in the language within the e-mail body and the style of e-mails and flags them as phishing attacks.  It also has the ability to create certain rules that will block any external e-mails that try and spoof the display names of your executive, which is an effective way to prevent those e-mails getting through to your organization. </span></span></span></span></span></p> <p><span><span><span><span><span>The other tool out there that I've seen is monitoring of domain names. Your organization has a domain name; some have multiple domain names. It costs little to register the domain names these days, so monitor names that are close to your company name(s) for any newly registered domain names that could be used to spoof your employees' e-mail addresses.</span></span></span></span></span></p> <p><span><span><strong><span><span><span>Recommendations for mitigating risk around social engineering</span></span></span></strong></span></span></p> <p><span><span><strong><span><span><span>Mike Pappacena:</span></span></span></strong><span><span><span> Something that's crucial is the multifactor authentication on any kind of email or perimeter access; when accessing systems remotely, instead of just putting in a username and password, you're also putting in a code that you'd get most typically as a soft token that's sent to your phone. If you get compromised with a password and someone gives up a password, if you have that second level of authentication in place, that's a mitigant.</span></span></span></span></span></p> <p><span><span><span><span><span>Most phishing e-mails are there to try to put in place some sort of business e-mail compromise, or BEC, to lead to an FTF, or funds transfer fraud. The goal is from a lot of these attackers, is to get someone to send out a wire. By putting in effective cash controls like calling back on wires and changes of contact information and having multiple approvals (so an individual can't set up a wire and do his or her own approval of a wire) all could also mitigate the risk of a loss. I've seen plenty of times where clients' environments have been compromised but because the schemers did not know the internal process around management and because of the cash controls that were in place, the firm was able to prevent something from happening.</span></span></span></span></span></p> <p><span><span><span><span><span>One more key take away around social engineering is to really understand the tone of the individuals that send something to you. As an example, if someone got an e-mail from Michael Pappacena, that would be a red flag because I go by Mike. You know in your organizations whether the partners go by nicknames, how they sign off an e-mail and how they address you with a salutation. The tone of an e-mail goes a long way to determine if the e-mail was legitimate, and if something doesn't sound right, chances are it isn't right, and you should always question the source.</span></span></span></span></span></p> <p><span><span><strong><span><span><span>Third party risk management</span></span></span></strong></span></span></p> <p><span><span><strong><span><span><span>Mike Pappacena:</span></span></span></strong><span><span><span> All of your service providers have access to very sensitive information, whether it's investor information, employee information, deal information or research information. You want to make sure that you vet these firms with some rigor.</span></span></span></span></span></p> <p><span><span><span><span><span>The first thing that firms need to do is to understand which of their third parties and vendors are riskiest. What data do these service providers have access to or custody of? All of that should be put into a bucket and categorized as a vendor that needs to be diligenced. In addition to that, look at the operational risk of the vendor. You may have a vendor that may not have access to very sensitive data, but operationally, if they struggle to provide the service you should also put them on that list and make those the critical vendors that you do a review of. Our recommendation is to do those reviews once a year or so, because environments change, and controls change, and you want to ensure that you understand that. </span></span></span></span></span></p> <p><span><span><span><span><span>One of the biggest gaps that we do see is folks going out and doing some level of diligence, and they don't necessarily follow through with the vendor or third party on remediation. With bigger vendors there may not be leverage for a firm to institute change, but what we do see across the landscape is that more and more of the large firms are hearing from more and more of the small and medium-sized firms that they do perform diligence and addressing cybersecurity risks are important to them. There's strength in numbers. </span></span></span></span></span></p> <p><span><span><strong><span><span><span>Where can firms make improvements to their cybersecurity testing and training program?</span></span></span></strong></span></span></p> <p><span><span><strong><span><span><span>Alex Beher: </span></span></span></strong><span><span><span>What is important is that there is a top down approach to testing and training within the organization, whether it's a password complexity policy, multifactor authentication, mobile device management, IT security policy or asset management. All of these policies should apply to every employee, regardless of their title and position in the company, and what we often see with some firms is that their leadership are being excluded from some of this. </span></span></span></span></span></p> <p><span><span><span><span><span>This presents a huge risk to the organization, as most of these people are high level and very high wealth individuals, and they're critical employees to the companies, and they should be protected the most. That's where the focus should be. If you do create those policies and employ those controls, you have to roll them out everywhere and to everyone.</span></span></span></span></span></p> <p><span><span><strong><span><span><span>Mike Pappacena: </span></span></span></strong><span><span><span>Some of the most effective training comes when you get someone who's an executive of the firm intro the training and let everyone know in the room that it's important. That tone from the top is hugely important.</span></span></span></span></span></p> <p><span><span><span><span><span>Specialized training is also important. Firms should have some additional conversations around the cash controls for those employees to make sure that those processes are followed. The executive administration staff has a lot of access to systems and processes that the executives themselves have, for example keeping custody of certain types of credentials and passwords. Performing some additional training with that staff would be beneficial because they have to worry about their own information and a senior executive’s. They're also a target to get to the senior executives. </span></span></span></span></span></p> <p><span><span><span><span><span>Lastly, when it comes to policy and policy enforcement, think about the consequences for not doing well on phishing tests. A lot of compromise and most of the breaches come through due to a phishing attempt or a successful phishing attempt. Really laying down the law with staff and saying that if you're failing phishing attempts and phishing tests, maybe there's some consequence. Weaving that in gets it out of the realm of cyber policy and into HR policy.</span></span></span></span></span></p> <p><span><span><strong><span><span><span>Final thoughts</span></span></span></strong></span></span></p> <p><span><span><strong><span><span><span>Alex Beher:</span></span></span></strong><span><span><span> When I think about cybersecurity and information security, to me it's a combination of technology, people and, processes. Firms need to take that approach to ensure they're properly protected. In this day and age, when we see technology advances happening so fast, it's just so easy to get stale and complacent. If you're not going to advance, you're going to be left behind and vulnerable.</span></span></span></span></span></p> <p><span><span><strong><span><span><span>Mike Pappacena:</span></span></span></strong><span><span><span> Make cybersecurity a program, not just a point in time exercise. The landscape changes, threats change. Stay on top of it and make sure that you evolve your program to address current threats and current thinking in this space. It's important that individuals take it to heart and almost take it home with them. What I mean by that is thinking about a lot of the best practices and things that your firm is doing and trying to take that home and being vigilant. What we often find is that folks that are more cybersecurity aware and savvy and practiced in their personal computing and personal use of information will carry this over to work, and vice versa. Making it a part of your culture and how you interact will help protect yourself and protect your organization.</span></span></span></span></span></p> <p><span><span><span><span><span>**********</span></span></span></span></span></p> <p><span><span><em><span><span><span><strong>Alex Beher</strong> and <strong>Mike Pappacena</strong> were talking to <strong>Mary Beth Hamilton</strong>, Vice President, Marketing, <a href="https://www.eci.com/"><strong>Eze Castle Integration</strong></a></span></span></span></em></span></span></p> <p>***</p> <p><em>The views expressed in this article are those of the author and do not necessarily reflect the views of AlphaWeek or its publisher, <a href="https://thesortinogroup.com/">The Sortino Group</a></em></p></div> <!-- END OUTPUT from 'themes/gavias_vinor/templates/fields/field.html.twig' --> <!-- THEME DEBUG --> <!-- THEME HOOK: 'field' --> <!-- FILE NAME SUGGESTIONS: * field--node--field-tags--features.html.twig * field--node--field-tags.html.twig * field--node--features.html.twig * field--field-tags.html.twig * field--entity-reference.html.twig x field.html.twig --> <!-- BEGIN OUTPUT from 'themes/gavias_vinor/templates/fields/field.html.twig' --> <div class="field field--name-field-tags field--type-entity-reference field--label-hidden field__items"> <div class="field__item"><a href="/hedge-funds-guest-articles" hreflang="en">Hedge Funds Guest Articles</a></div> </div> <!-- END OUTPUT from 'themes/gavias_vinor/templates/fields/field.html.twig' --> <drupal-render-placeholder callback="flag.link_builder:build" arguments="0=node&amp;1=1763&amp;2=bookmark" token="YFKE6Fb-W_ZeyNQgo1jQ461PxRhIhW_4yir9grHTo2w"></drupal-render-placeholder> <!-- THEME DEBUG --> <!-- THEME HOOK: 'field' --> <!-- FILE NAME SUGGESTIONS: * field--node--field-author--features.html.twig * field--node--field-author.html.twig * field--node--features.html.twig x field--field-author.html.twig * field--entity-reference.html.twig * field.html.twig --> <!-- BEGIN OUTPUT from 'themes/gavias_vinor/templates/fields/field--field-author.html.twig' --> <a href="/author/eze-castle-integration" hreflang="en">Eze Castle Integration</a> <!-- END OUTPUT from 'themes/gavias_vinor/templates/fields/field--field-author.html.twig' --> <!-- THEME DEBUG --> <!-- THEME HOOK: 'field' --> <!-- FILE NAME SUGGESTIONS: * field--node--field-content-role--features.html.twig * field--node--field-content-role.html.twig * field--node--features.html.twig * field--field-content-role.html.twig * field--list-string.html.twig x field.html.twig --> <!-- BEGIN OUTPUT from 'themes/gavias_vinor/templates/fields/field.html.twig' --> <div class="field field--name-field-content-role field--type-list-string field--label-above"> <div class="field__label">Content role</div> <div class="field__item">Public</div> </div> <!-- END OUTPUT from 'themes/gavias_vinor/templates/fields/field.html.twig' --> Wed, 07 Nov 2018 15:03:45 +0000 AlphaWeek Staff 1763 at https://alpha-week.com Nine Steps To Creating An Information Security Plan https://alpha-week.com/nine-steps-creating-information-security-plan <!-- THEME DEBUG --> <!-- THEME HOOK: 'field' --> <!-- FILE NAME SUGGESTIONS: * field--node--title--features.html.twig x field--node--title.html.twig * field--node--features.html.twig * field--title.html.twig * field--string.html.twig * field.html.twig --> <!-- BEGIN OUTPUT from 'core/modules/node/templates/field--node--title.html.twig' --> <span>Nine Steps To Creating An Information Security Plan</span> <!-- END OUTPUT from 'core/modules/node/templates/field--node--title.html.twig' --> <!-- THEME DEBUG --> <!-- THEME HOOK: 'field' --> <!-- FILE NAME SUGGESTIONS: * field--node--created--features.html.twig x field--node--created.html.twig * field--node--features.html.twig * field--created.html.twig * field--created.html.twig * field.html.twig --> <!-- BEGIN OUTPUT from 'core/modules/node/templates/field--node--created.html.twig' --> <span>Fri, 10/26/2018 - 09:41</span> <!-- END OUTPUT from 'core/modules/node/templates/field--node--created.html.twig' --> <!-- THEME DEBUG --> <!-- THEME HOOK: 'field' --> <!-- FILE NAME SUGGESTIONS: * field--node--body--features.html.twig * field--node--body.html.twig * field--node--features.html.twig * field--body.html.twig * field--text-with-summary.html.twig x field.html.twig --> <!-- BEGIN OUTPUT from 'themes/gavias_vinor/templates/fields/field.html.twig' --> <div class="field field--name-body field--type-text-with-summary field--label-hidden field__item"><p><span><span><span>Global IT provider, Eze Castle Integration, has been running an educational program for October’s ‘Cyber Security month’ and on Thursday, October 4th, hosted a webinar entitled ‘9 Steps to creating an Infosec plan’. AlphaWeek is publishing edited transcripts of these webinars. The speakers are Matt Donahue, Business Continuity Consultant, and Steve Banda, Senior Product Manager, moderated by Olivia Munro, Senior Marketing Specialist.</span></span></span></p> <p><span><span><span><strong>Nine Steps to Creating an Infosec Plan</strong></span></span></span></p> <p><span><span><span><strong>Matt Donahue:</strong>  I review a lot of different types of information security plans. They come with different titles and names, but typically they include a collection of different policies, procedures and guidelines. Policies should be high level and don't need to get granular. They should be relatively static. Procedures and guidelines tend to be more dynamic, and they should because they are based around the people, process and technology, and as those things change within a firm, so should the procedures and the guidelines. </span></span></span></p> <p><span><span><span>When you are developing a plan or re-evaluating it, finding a template online is going to be helpful in putting it together but it needs to be customised to your actual organisation and to the expectations of certain activities that are going to be completed without it. There are a lot of things that need to be reviewed and maintained, and it's not something that can happen overnight, so it does take work. </span></span></span></p> <p><span><span><span><strong>Step 1: Regulation and Industry Best Practice</strong></span></span></span></p> <p><span><span><span>The first step in developing it is to start with the requirements and what you need to do based on the regulatory landscape that you face. A lot of firms are going to be subject to regulation by different federal or international bodies or agencies. Understanding all these different kinds of considerations and their requirements is key. Different types of authorities, in different industries within different jurisdictions have certain requirements that your business might be subject to. It’s a layer that you're going to have to examine to make sure that you're on the same page. </span></span></span></p> <p><span><span><span>There are other industry-specific self-regulatory or self-imposed groups that have different practices or requirements for both information security and continuity that you should be aware of. A lot of the pressure that a lot of firm’s face comes from the external pressures from investors or auditors or external parties. They're asking about these different types of activities that you may or may not be doing. They're requesting that you do some of these other types of services or activities. There's a lot of pressure coming in, not only from the regulatory bodies, but also from external pressures that are not specifically a regulator. </span></span></span></p> <p><span><span><span><strong>Step 2: Internal Responsibilities</strong></span></span></span></p> <p><span><span><span>Once you have a good understanding of step 1 it's also good to look at responsibility within your own firm; who is going to supervise this and who is going to be responsible for it? Governance oversight is really about the responsibility, but a lot of this has to do with expectations, both within your own firm within the various roles as well as some of the different parties that you work with. Initially, you should look at who's going to be responsible for these plans, these programs, and the different activities that happen, so that you can create a schedule of the different things that you want to have happening throughout the year, like your annual reviews. </span></span></span></p> <p><span><span><span>Having specialized teams of people being aware of what they need to be doing during these time periods is critical for communicating correctly if there are any issues. A missed communication could mean that different threats can go undetected for longer periods of time. Another thing to consider is your expectations of vendors or service providers because if there's an incident that might impact their firm, you're going to want to know how they're going to communicate with you, what the expectations are in terms of service level agreements and making sure that everything is covered. If a critical tool that you use is down, you want to work with those groups that are going to be responsive, so it's about making sure that everybody is aware of the responsibilities and the expectations on both sides.</span></span></span></p> <p><span><span><span><strong>Step 3: Asset Inventory</strong></span></span></span></p> <p><span><span><span>Take an asset inventory. When I mean assets, I'm talking both hardware, like physical devices, and software, like systems and different applications. It's really just taking a look and seeing what you have. This should be something that is kept up to date as frequently as possible. Tools are available for this; some are a pay for service and some of them are community, or free online. They can help you to manage this process with some continuous type of cadence.</span></span></span></p> <p><span><span><span>You don't want to have people with different types of hardware that you're not aware of attached to your network or different types of software that they might be downloading; essentially, anything that you can't account for, because you can't determine what the risks might be. Even if it’s coming from a good source, those are the things that you want to control and avoid, and not allow people to bring into your network or into your firm.</span></span></span></p> <p><span><span><span>Taking an asset inventory allows you to prioritise them. Talk about the criticality to the business; classify them accordingly. This helps not only from an organisational standpoint, but also in determining risk.</span></span></span></p> <p><span><span><span>Understanding the value to the business of all of your assets enables you to determine what that asset value is on an annual basis. Depending on what it's used for, you then can make more informed decisions regarding risks or disruptions to your business that might be caused from either cyber security-type events or from other events like a continuity issue. It's good to have some metrics in that place around that.</span></span></span></p> <p><span><span><span><strong>Step 4: Data Classification</strong></span></span></span></p> <p><span><span><span>You should be classifying the different information that you collect, share, and have obtained, whether that is personally identifiable information, protected health information, not-public information, even financial data. Some of these data might not be defined in the same way in the same place; different jurisdictions have different definitions. It's important to know what those definitions are and how that information is handled internally at your firm.</span></span></span></p> <p><span><span><span>You should also look at where this information resides within your organisation. How is it brought into your organisation? How is it managed? What retention policies might be in place? Who has access to it? Oftentimes, once you can classify it, you can come up with a process and role-based access privileges so that people who shouldn't be accessing the data cannot. </span></span></span></p> <p><span><span><span>Once you have achieved this, you can audit it. One option to do that is to run a tracer, so if you're looking at a business process or a data type you can see where it would come into your organisation and where it stays. Again, retention policies should be in place. </span></span></span></p> <p><span><span><span>Working on a unit-by-unit type of approach is also recommended because there's a lot of work that goes up and downstream. One department may not realise that another department is using the same information and is storing it in different locations. Working with the different business owners and different groups is a good way to help ensure that everything's accountable up and down the line.</span></span></span></p> <p><span><span><span><strong>Step 5: The Available Security and Safeguards</strong></span></span></span></p> <p><span><span><span><strong>Steve Banda:</strong> The classification and protection of data is an essential part of the security plan, but the variety of technology systems needed to protect data can seem overwhelming.</span></span></span></p> <p><span><span><span>One way to think about this is to apply different layers of protection. It's important to keep in mind your evaluation of your organisation and where there may be gaps within your organisation relative to this.</span></span></span></p> <p><span><span><span>First, there is the perimeter network security; antivirus, patching, email security, spam filtering solutions, firewalls, etc. This could also encompass your intrusion detection or prevention systems. These are the perimeter network security components to keep in mind.</span></span></span></p> <p><span><span><span>Next, you will have your access control measures. You need to make sure that you have secure remote access when connecting remotely from outside the office. Additionally, by utilising a mobile device management tool (MDM) you can ensure that if a mobile device is lost or stolen, your IT firm or your firm can remotely wipe the device, preventing data from being compromised. </span></span></span></p> <p><span><span><span>Then you want to have the balance between your written safeguards and your technical safeguards and the controls that you implement. Document the procedures and the technical safeguards; they work together and support one another, enhancing your plan as a whole.</span></span></span></p> <p><span><span><span>Employees are the first line of defence, so you want to make sure that users have strong passwords and that they're updating them frequently, and that they're automatically enforced through group policies.</span></span></span></p> <p><span><span><span>Finally for this step you have your critical component of testing employees through various situations, such as phishing and training exercises or completing cyber security training. All of this works together to really enhance the security of your plan and make sure that you're backing up whatever is written.</span></span></span></p> <p><span><span><span><strong>Step 6 – Cybersecurity Risk Assessment</strong></span></span></span></p> <p><span><span><span>Once you have the security controls and policies written and in place, a good next step is to consider doing a cyber security risk assessment of your firm. The goal here is to understand the cyber security risks to the operation, the functions, the reputation, and the organisational assets of your firm. It's a balance between what risks are acceptable to you and your business and which ones you'd like to take actions against, whether that means mitigating these, creating contingency plans, or just accepting that risk and leaving it as it is.</span></span></span></p> <p><span><span><span>However, this is also where you look at the company's culture, the cost, and any other potential problems that you may encounter if you choose to implement a strategy. For example, what is the impact on the organisation from employing multifactor authentication where users would have to log in and enter a code from their phone? It could be negative, it could be positive. What's the long-term benefit to your business?</span></span></span></p> <p><span><span><span>Either way, based on the resources that you want to spend, you need to make good business decisions for your firm. Conducting a risk assessment typically involves performing an internal or external vulnerability assessment, which could lead to the exposure of potential threats, or looking at some of the external resources or third parties and where the threat lies there, and then determining your enterprise risk and likelihood and coming up with an action plan. You want to identify and prioritise the risk responses, so you know which ones you are responding to first. Most companies conduct routine vulnerability assessments and have software and tools that can scan the network to determine what services are running or what might look out of place.</span></span></span></p> <p><span><span><span>A key message here as well is that if you're not conducting risk assessments today, you certainly can start small and evolve. There's a lot of guidance out there that recommends completing robust cyber security assessments. Whilst this is recommended by us as a best practice, the key message is if you don't have something in place today, starting small and letting the process mature as you evolve is a key message and key takeaway here for cyber risk assessments.</span></span></span></p> <p><span><span><span><strong>Step 7 – Third Party Vendors</strong></span></span></span></p> <p><span><span><span>We really see a potential for increased risk and exposure as firms leverage more outside firms or more third-party relationships to provide their solutions to their customers and to support their business so it's really important to look at your third-party vendors to see what the expectations that you need to set with your third parties are, so you can manage the relationship effectively.</span></span></span></p> <p><span><span><span>We suggest having a process and a checklist in place for all your vendors so that you can send these to them annually and make sure that they're establishing the guidelines that your business establishes as acceptable, particularly around the IT policies of that third party. Here you really want to understand what their written and acceptable use policies are and any workaround solutions that they have in place in case your data is compromised. </span></span></span></p> <p><span><span><span>One of the common things to look out for involves if they have access to your firm's confidential information. How are they storing it, how long are they keeping it for, and what employees at their firm would be accessing that information? Are they SOC II compliant? For example, Eze Castle's cloud services are SOC II compliant, and audited annually to ensure compliance. You're going to want an official audit report from your third party. How often do they have a third-party security and penetration test done to their network, or how well do they train their employees in their policies and their procedures? It's all part of the vendor life cycle. You should be reviewing the critical vendors at least annually to discover any changes to their solutions, and consequently if it's worth staying with that vendor, or moving to another.</span></span></span></p> <p><span><span><span><strong>Step 8 – Creating an Incident Response Plan</strong></span></span></span></p> <p><span><span><span>It's not if, but it's when a breach is going to happen. Having a proper incident response plan in place is crucial for that. When an incident does occur and disrupts the day-to-day running of your  business, you will have outlined the actions that those responsible should take. We do see instances of response plans being a little light, but you do need to have a plan and assume that's going to happen at some point. Your plan needs to be realistic and specific to your firm, and your vendors may have a stake in understanding which other vendors may have a stake in your response as well. </span></span></span></p> <p><span><span><span>When creating this plan, one key message here is it should be a collaborative effort with external and internal parties, including people from operations, personnel, HR; any specific employees that would know how to properly respond to events should be included. It's not appropriate to pin this on one person or one vendor. All departments outside counsel should be reviewing this to see if there are any areas that might have been missed. It's conducting due diligence on your own policies by including the individuals from various disciplines within and external to the organisation. Having these conversations ahead of time is important because it's going to set the expectations, the roles and responsibilities so that you can execute these correctly when that incident does occur. It's not something you want to leave until the last minute; you want to get ahead of it and do it upfront. Two table-top exercises include running through the actual breach scenarios, and the procedures that you have in place to support the response. </span></span></span></p> <p><span><span><span>This is a living document that you'll need to constantly evaluate. Making sure it's accurate and realistic for your firm on an ongoing basis is critical. </span></span></span></p> <p><span><span><span><strong>Step 9 – Testing and Training Your Employees</strong></span></span></span></p> <p><span><span><span><strong>Matt Donahue</strong>: It's one thing to have these different plans, but you need to get people to take those and make those specialised tweaks based upon experiences. You need to walk people through them, make them understand it, and you need to train people on the policies and procedures. If you don't have people understanding what their responsibilities are and what they're supposed to be doing then it's hardly fair for you to have any expectations of them following it. Annualised training on the policies and procedures for all employees in the firm should be a minimum. Review any specific role responsibility; if you're an employee with responsibilities in a team that's going to be handling an incident, your training should obviously be general as your other employees would receive, but it should also be specific to your roles. The expectations are that they get you a little more acclimated to what those special types of responsibilities are, and a little bit more experience so you can better handle it if an incident does come up.</span></span></span></p> <p><span><span><span>You should potentially simulate different types of incidences, and you can do those two different table-top exercises; they're no fault, light cost if you have the time to do them. Walking through these and getting people familiar with the process enables you to understand and learn from situations like "that was the stuff we wrote down, but that actually wouldn't work here because so and so wouldn't be doing this, or he'd be focused on that or she'd be communicating to these parties." That's how you can really make sure that everything's going to be accurate the way it should be. </span></span></span></p> <p><span><span><span>Another thing to look at is different types of simulations. Phishing is a major threat, and something that continues to be an issue year on year. Sometimes it's hard to prevent employees from clicking on them because it does come from a domain that's close, and it does look like it's going to be something that's going to be clicked on. So, it's not an imperfect thing if there's a human element to it, but training and educating them and testing them enables you to get the metric to see if things are going well. Testing your policies and your plans, auditing them, it's always useful as well to show that you're going through additional steps to make sure that things are the way that you have it spelled out, and they're following better practices.</span></span></span></p> <p><span><span><span><strong>Final Thoughts</strong></span></span></span></p> <p><span><span><span>When you're looking at different types of information security plans or plans in general, if you haven't done these things or you're not competent in them based upon what we talked about today, it's probably a good time to develop them or to re-evaluate them. And it should be a cyclical approach where every year you review the different items that you're going to be doing. There's the policy side, there's the technology side, there's the incident response areas. All of these things should be reviewed and updated as needed, but at a minimum annually. So if you haven't done it, start doing it, otherwise you're putting yourself at risk from a fine or something worse.</span></span></span></p> <p><span><span><span>**********</span></span></span></p> <p><span><span><span><em><strong>Matt Donahue</strong> and <strong>Steve Banda</strong> were talking to <strong>Olivia Munro</strong>, Senior Marketing Specialist, <a href="https://www.eci.com/"><strong>Eze Castle Integration</strong></a></em></span></span></span></p> <p>***</p> <p><em>The views expressed in this article are those of the author and do not necessarily reflect the views of AlphaWeek or its publisher, <a href="https://thesortinogroup.com/">The Sortino Group</a></em></p></div> <!-- END OUTPUT from 'themes/gavias_vinor/templates/fields/field.html.twig' --> <!-- THEME DEBUG --> <!-- THEME HOOK: 'field' --> <!-- FILE NAME SUGGESTIONS: * field--node--field-tags--features.html.twig * field--node--field-tags.html.twig * field--node--features.html.twig * field--field-tags.html.twig * field--entity-reference.html.twig x field.html.twig --> <!-- BEGIN OUTPUT from 'themes/gavias_vinor/templates/fields/field.html.twig' --> <div class="field field--name-field-tags field--type-entity-reference field--label-hidden field__items"> <div class="field__item"><a href="/hedge-funds-guest-articles" hreflang="en">Hedge Funds Guest Articles</a></div> </div> <!-- END OUTPUT from 'themes/gavias_vinor/templates/fields/field.html.twig' --> <drupal-render-placeholder callback="flag.link_builder:build" arguments="0=node&amp;1=1725&amp;2=bookmark" token="ca1CArtUsFaz7yLrNGSaUozVi0vO_9QG-0TCHnI87O0"></drupal-render-placeholder> <!-- THEME DEBUG --> <!-- THEME HOOK: 'field' --> <!-- FILE NAME SUGGESTIONS: * field--node--field-author--features.html.twig * field--node--field-author.html.twig * field--node--features.html.twig x field--field-author.html.twig * field--entity-reference.html.twig * field.html.twig --> <!-- BEGIN OUTPUT from 'themes/gavias_vinor/templates/fields/field--field-author.html.twig' --> <a href="/author/eze-castle-integration" hreflang="en">Eze Castle Integration</a> <!-- END OUTPUT from 'themes/gavias_vinor/templates/fields/field--field-author.html.twig' --> <!-- THEME DEBUG --> <!-- THEME HOOK: 'field' --> <!-- FILE NAME SUGGESTIONS: * field--node--field-content-role--features.html.twig * field--node--field-content-role.html.twig * field--node--features.html.twig * field--field-content-role.html.twig * field--list-string.html.twig x field.html.twig --> <!-- BEGIN OUTPUT from 'themes/gavias_vinor/templates/fields/field.html.twig' --> <div class="field field--name-field-content-role field--type-list-string field--label-above"> <div class="field__label">Content role</div> <div class="field__item">Public</div> </div> <!-- END OUTPUT from 'themes/gavias_vinor/templates/fields/field.html.twig' --> Fri, 26 Oct 2018 08:41:40 +0000 AlphaWeek Staff 1725 at https://alpha-week.com