Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Case study: Getting a grip on application risk

17 views

Published on

Iceberg recently helped a large North American bank with an Application Risk Management project using the RSA Archer platform. Their goal was to create a process that would allow them to make risk-based decisions in order to make better use of their resources. Although the scale of this project was very large, the approach they took is relevant to organizations of any size.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Case study: Getting a grip on application risk

  1. 1. www.icebergnetworks.com Delivering Risk Intelligence CASE STUDY Getting a grip on application risk Centralizing & automating application risk assessments at a North American bank How many applications are deployed within your organization? Which of those applications are linked to critical business processes? When was the last time you ran a risk assessment on each of them? How should you prioritize the applications that need attention today? Are you sure your risk mitigation dollars are being spent effectively? Most organizations struggle to come up with confident answers to these questions. That’s a big concern, considering that companies rely on applications to deliver the vast majority of products and services. Risk assessments that do exist are often out of date or are spread out in various spreadsheets and archives. Why is application risk management so important? With IT and information as the backbone to any business, the applications that are deployed become the pathway to data. Everyone who relies on that infrastructure ­— employees, customers, suppliers ­— wants to have confidence in the confidentiality, integrity, and availability of the data and the applications that access it. Without an effective application risk management program, organizations could face IT failures and reduced performance; they are at risk of privacy and security breaches; they may not meet the requirements of auditors and regulators; and ultimately they may lose the ability to deliver products and services. Most importantly, since companies have limited resources for risk mitigation, they need to ensure they are using these funds as effectively as possible. Having a clear understanding of their application risk posture gives managers confidence that they’re spending money in the right places. CASE STUDY: From spreadsheets to centralization Iceberg recently helped a large North American bank with an Application Risk Management project using the RSA Archer platform. In the case of this financial institution, they had over 2,000 applications, and our engagement was over the last two years of a five-year journey. Their overall goal was to be able to confidently answer questions like the ones above. They wanted to make risk-based decisions in order to make better use of their resources. They knew they needed to centralize their disparate spreadsheets, although at the onset it was not entirely clear how they would accomplish that. The scale of this project was very large. Although thousands of applications and multi-year timeframes are typical for a large bank, the approach they took is relevant to organizations of any size. What’s important here is that the process sequence and the lessons learned are very applicable to both large and small organizations, and whether you’re dealing with a few dozen or a few thousand deployed applications. by Kirk Hogan, COO, Iceberg
  2. 2. www.icebergnetworks.com Delivering Risk Intelligence STEP ONE: Inventory & categorization For this particular bank, their journey goes back five years. At the time, each line of business (LOB) had their own lists of applications kept on spreadsheets. They knew (or at least they were reasonably certain!) that they had over 2,000 applications in their inventory, but that list was spread out over each LOB and there was no formal categorization. Which applications supported business operations? Which ones were technology applications? In other words, they had a huge unordered list of apps, without any meaningful data to make risk decisions on. At this point in their maturity determining which applications were the most important to the business would have been largely a guesswork exercise. For example, they knew that SAP was a really important application, but they didn’t have any solid data to prove how many business processes were dependent on it. So step one for them was categorization. Their basic criteria was: Which applications does our business need to run? Which ones do we rely on to deliver our core processes? Based on the inventory and information that they had, they identified 1,800 applications that they believed were business-critical and that they wanted to target for risk assessments. They had a team of about 30 business technology risk managers spread out between six LOB’s, tasked with doing an initial assessment of those 1,800 applications. For the most part those managers all worked within their own units and created their own spreadsheet questionnaires and collected the data. There was no agreed-on framework for measuring and reporting on risk. STEP TWO: Harmonization Here was their first “AHA!” moment: They started to realize that they were all asking similar questions. Now that probably sounds obvious in hindsight, but if you know how the internal org structure and politics of a large banks work, it won’t be too surprising! So their next step was a decision to build a common framework to properly consolidate and co-ordinate their assessment process. Working with an outside consultant, and with strong support from leadership, before long they narrowed a few dozen risk assessment spreadsheets down to a set of four or five spreadsheets, each representing a co-ordinated question set. With a common question set, and a consistent risk framework, they could now generate better, more reliable data. This wasn’t an easy task and involved some give-and-take. It was important to not take away the autonomy of each LOB to assess risk, because ultimately the LOBs are the ones that own the risk. They started to achieve alignment when the various stakeholders realized that with a good set of questions, leading to a harmonized set of assessments, they could have a much more effective risk management program. Eventually they worked their way to a state where everyone tasked with assessing risk, regardless of the LOB, was using the same template, based on one spreadsheet. STEP THREE: Automation So now we’re a few years into the program. Up until this point, all the application risk information was being maintained on spreadsheets. The thing about spreadsheets is they’re good by themselves, but when you try to co-ordinate hundreds or thousands of spreadsheets (each with hundreds of rows), you have to do an awful lot of linking. 508Average # of applications per enterprise1 1 Netskope survey, 2014 2 Veracode survey, 2015 22%Percentage of cloud applications believed to remain invisible to IT.1 >2,000Average number of unsafe mobile apps installed on employee devices.2 85%Percentage of data uploaded to apps that allow file sharing.1 85%Of those unsafe apps, percentage that exposed sensitive data such as device location, call history, contacts, SMS logs, SIM information2
  3. 3. www.icebergnetworks.com Delivering Risk Intelligence Believe it or not the bank actually had professionals linking spreadsheets together. Think about the cost implication of having professional “linkers”, spending their hours making cross-references within the various spreadsheets across the LOBs. This is the point where they started looking at platform solutions to centralize everything and move away from spreadsheets. They ended up picking RSA Archer to be that initial risk platform, which would link together the inventory of applications, and the inventory of the controls that mitigated the risk. They took the single Excel spreadsheet assessment template, and converted it into an online assessment form on Archer. The collection of information could now be automated, with users logging in to fill out their answers and upload documents on the platform. Where previously the assessors had to interview the application owner, interview the people who owned the controls, and then go and get evidence that the controls were in place — now that could all be done online. Instead of being kept on different laptops and sharepoint drives, the information collection was now done in real time, attached to records within the platform. Remember those professional “linkers” who were collating Excel sheets? Now they could go back to their regular jobs: assessing risk! When people talk about automation, often it’s linked to the idea of reducing human resources. In our experience usually we are not eliminating positions — just re-assigning people to more useful work. STEP FOUR: Risk-based prioritization With all these assessments running through Archer, the bank started to build up a very accurate, thorough and clean inventory of information: applications, controls and assessments. Now they could finally start prioritizing risk management activities. Risk is a combination of likelihood and impact. The assessments help determine the likelihood ­— basically the fewer controls that are met, the more likely an event. The impact is based more on business continuity considerations: what’s the impact on my ability to deliver products and services if this application isn’t available? To determine risk, we combined those two factors together. Every application gets a basic risk rating on a scale of 1 to 5 (low to high), along with a weighted risk score. You might have 1,500 applications come out as “high risk”, but within that there will be a range of scores to help you prioritize which ones need attention first. The weighting was accomplished by assigning specific control profiles to mitigate risks based on the application type. The state of the controls assigned to each application, as well as the risk rating assigned by the risk assessors, helped to create the needed separation between the many risk scores calculated for all the applications in the LOB. So now each LOB could begin prioritizing where money and resources were targeted to address the most critical risks and applications. They could base those decisions on standardized data ­— something they could not have accomplished at this scale using spreadsheets. Another interesting benefit that they realized: Now that they were using a common risk framework and consistent risk scores, they could look across the organization and see where there were discrepancies in assessments between the LOBs. They had a centralized governance group looking across the organization, and saw that some applications were rated by one LOB as a 5, and a different LOB rated it as a 4. They could start to ask questions to understand why there were differences. The importance of leadership This project benefited from strong executive leaders in the organization. Essentially it was a single point of governance — one executive — who said “thou shalt” and gave a clear direction. That was very important to achieve this evolution. Without, it would have been very hard to navigate the politics and co-ordinate work between various groups in the organization. They also benefitted from having a leader who’d been through a similar process before. One of his key insights was that before they put their assessments on a platform, an important first step was to make sure their data was as tight, clean and consistent as possible. It may have taken five years to get from A to B, but the extra time they took to get through each stage kept everyone on board, built up momentum and buy-in, and ultimately resulted in an effective solution.
  4. 4. www.icebergnetworks.com Delivering Risk Intelligence Keys to Better Reporting I like to think of effective reporting as being like the cockpit of an airplane. You don’t want to inundate a pilot with everything that’s going on. If the oil pressure is good, you don’t have to tell her about it. If the pilot starts to see a low fuel warning light, she knows right away it’s a critical warning. You need to give the pilot the information she needs to see at the time she needs to see it. Every dashboard or report designed and configured has to have a defined purpose In this organization, most managers were making decisions on a weekly basis, asking “how am I going to change my program this week to make sure that we’re focused on the right things”. There still might be 400 applications with “high” or “very high” risk ratings, but typically the managers want to see a filtered list of only the “top 10” or “top 100” risks. That’s what they need to see in a dashboard or report. This bank uses the concept of “actionable metrics”. They’re looking for more than just reports and statistics. Within Archer an executive can drill down and see what the action plan should be to remediate the risk, and what the status is of that plan. So for example, a risk manager might have identified a gap, and has recommended that a system needs anti-malware protection. The action is that the owner has to prove that anti-virus or anti-malware is protecting this application. When the action is complete, the platform can show a change record where this application is now filtering all traffic through this central available system. The executive who owns that application can see the remediation action plan and evidence that the control is in place, and therefore that the control gap has been addressed. That kind of drill-down transparency in the process is not possible with spreadsheets, but it’s integrated throughout the Archer platform.
  5. 5. STEP FIVE: Measure & improve Our approach on this project was, don’t strive for 100% perfection. We worked towards getting 80% correct, and then making small improvements from there. The process of moving from Excel spreadsheets to automated questionnaires is a good example. We didn’t try to over-engineer the solution in the beginning. We resisted the urge to categorize everything into rigid values lists. To start, we categorized four or five attributes in the questionnaire, but for the rest we allowed free-form values. After a few months of using that questionnaire, we analyzed the answers and responses, then worked with the bank to refine the questionnaire for version 2.0. That made the system smarter and more responsive to how users wanted to respond. It was a great evolutionary step, and it resulted in even better reporting. On the program strategy side, initially, their approach was to over-compensate. If there were 400 high-priority applications, they wanted to make sure they had an action plan to remediate all the risks. Now that they’ve accomplished that first wave over the last couple years, they have more data to help understand how they can better prioritize their risk remediation. In other words, now they can start to say: we can live with that risk. Another area they’ll tackle soon is around performance metrics. So far they’ve been focused on effectiveness first, and then efficiency, which is right order. Throughout the process they have been gathering information to give them a baseline to understand how the platform can improve efficiency. Achieving value Today there are about 100 active users on the platform, but the platform impacts tens of thousands of employees who rely on business applications to do their jobs. Five years ago, this bank was making application risk management decisions largely on gut or guesswork, and for the most part within the silos of each LOB. They had no effective way to cross-link assessments and had inconsistent data. With the RSA Archer platform in place, they are further along the journey to achieve “Risk Intelligence”: they have trusted, transparent and aggregated risk data, and the ability to make informed, confident and effective decisions. Ultimately they’re in a much better position to react quickly to change, and move more quickly to take advantage of opportunities that will allow them to grow their business. Kirk Hogan is the Chief Operating Officer at Iceberg, managing the delivery of Iceberg’s GRC Centre of Excellence program. For more information or to request a demo, contact Kirk at khogan@icebergnetworks.com ® PREMIUM PARTNER Iceberg Networks USA: 67 Bedford St. • Suite 400 West • Burlington, MA • 01803 CANADA: 600-515 Legget Drive • Ottawa, Ontario • K2K 3G4 Toll Free: 855-595-0808 • info@icebergnetworks.com Twitter: @icebergnetworks • Blog: icebergnetworks.com/blog About Iceberg Iceberg is a Value-Added Partner (VAP) for RSA Archer, delivering software and services to help our clients successfully deploy Governance, Risk & Compliance (GRC) technology. Headquartered in Ottawa, Canada and serving all of North America, our team of over 20 certified and practicing RSA Archer experts offer a full lifecycle of consulting and services through our Centre of Excellence. Our missions is to help our clients achieve trusted, aggregated and transparent risk intelligence that enables their business to make more informed business decisions.

×