1. Making Information Security Strategic through GRC
Good morning
My name is Tony Rock. I am the VP of Business Development for Lockpath, a technology-enabler of enterprise risk and compliance solutions. I have worked in technology and innovation for 25+ years and have lead several engagements for IT compliance and risk management.
LockPath makes a software platform called Keylight that helps users manage Governance, Risk and Compliance activities, or GRC, across their enterprise. I will tell you a little more about Keylight at the end of the presentation today.
[CLICK]
Tony Rock
VP, Business Development

2. What you will learn GRC concepts and components
What InfoSec data is used in GRC programs
What actions can I take with this data
What will I get and who will care
Today we will be talking about GRC – what it is, why it’s important.
We’ll then talk about GRC as it applies to Information Security and how you can apply GRC concepts to your Information Security programs.
[CLICK]

3. What is GRC?
So what is GRC? Raise of hands -- How many of you are involved in a GRC program?
Ok… How many of you know what GRC is?
Don’t worry – you’re not alone. The technology analyst firm, Gartner, surveyed their clients in 2015 and found that 65% of their clients didn’t know the term GRC.
However in a separate survey, 65% of global CEOs and senior executives said they view the level of investment in risk management tools and practices as falling behind. So risk management has become a company-wide initiative.
And that’s where GRC comes in.
[CLICK]

4. Governance, Risk Management and Compliance (GRC)
an integrated capability to reliably achieve objectives [Governance], while addressing uncertainty [Risk management], and act with integrity [Compliance].
On the screen you’ll see an industry definition of GRC.
In the real world it’s nothing more than: - identifying your goals - identifying what could prevent you from meeting your goals - and fulfilling expectations of management
So why would we even want to use GRC processes?
[CLICK]

5. Why GRC? “We just suffered a major incident related to XYZ assets."
“The risk and compliance system we were using was not integrated and based on Sharepoint and spreadsheets.”
Let’s take a worst case scenario.
Who here comes from a large organization and has interaction with or responsibility to provide information to your Board of Directors?
Who has gotten some pretty urgent s from their boss to give them information that the Board needs?
Of those with your hands raised, how often do those questions seem off the wall in terms of urgency or topic?
Weird things can happen to people when they have to report things to a Board committee. That’s because when a Board member gets wind of things, questions fly fast and immediate response is expected.
By employing GRC processes, you can avoid some of those late phone calls and text, long days, auditors, and s from people that you’re not sure it’s a good thing they know your name.
[CLICK]

6. Why GRC? What do we put in place to keep that call from happening?
Password complexity
Infrastructure design
Data classification
Device/asset provisioning
Vulnerability scanning
Alignment with regulatory expectations
So how do we do this?
We apply multiple layers of oversight to identify and monitor processes and controls.
We need to validate what we’ve put in place is actually working and evolving, while aligning with management expectations.
One avenue for demonstrating that is applying controls that require devices on the network be reviewed before being deployed, asking what classification of data is on those devices, then scanning network segments those devices and that data resides on.
How many of you are doing these things already?
Well then you’re already employing a portion of GRC.
[CLICK]

7. The Next Frontier Getting better is Data integration not good enough
is the key
Rate of technology change and customer expectations is greater than the rate of improvement
Shifting risk to third parties for support services has limitations
Stakeholders now expect more holistic views on risk
Compliance and Risk information is linked to all IT security and critical business processes
Vendor risk management is more robust
Evidence of compliance (audits, documentation, signoff) is digitally centralized
So while we’ve seen growth in the importance of the InfoSec organization over the last decade, there is still much more work to be done for the future.
The challenge is that rapidly advancing technology platforms --- the movement to the cloud, pervasiveness of mobile devices, the internet of things, drones, artificial intelligence, as examples --- have created a degree of connectivity that has never existed in human history. It is this connectivity that is spurring a wave a new opportunities for businesses, while exposing a number of new threats and vulnerabilities that must be dealt with from a risk and compliance standpoint.
As an example, companies seek to shift technology management and resource bottlenecks to outside parties, ranging from standard vendor relationships to strategic outsourcing. The relief of their pain is hollow and short-lived as this behavior mitigates one set of risks and increases others. And if these companies are operating in a highly regulated environment, their compliance headaches just went up as dealing with compliance issues with external parties is time consuming and costly.
Stakeholders --- management, investors, board, key customers, regulatory bodies, etc. --- are aware of these technology trends and expect more governance and transparency, and they expect to see it sooner than later.
The InfoSec organization is uniquely positioned to help lead the organization in dealing with tomorrow’s challenges through a GRC framework. Automation, data integration and robust vendor management will be some of the key principles to enable the business going forward. InfoSec needs to reach out demand to build in security and compliance into strategic projects before they are launched, otherwise it just adds avoidable costs and complexity.
The reality is if we are doing our jobs, we shouldn’t even sound like a security person. The enterprise doesn’t care how many viruses we’ve stopped. They don’t care how many cases we wrote. They want to know how we, the InfoSec profession, are helping them meet their objectives.

8. Common GRC Concepts in InfoSec
Risk-based security initiatives
Gap analyses between controls and processes
Escalation of critical threats and incident response transparency
Board-level reporting of security metrics, trend analyses and financial impacts
We often see common components being used by Information Security teams to further the effective use of GRC. They help to provide results to teams regardless of where they are in the organization, and help an organization employ a risk-based approach to compliance and security initiatives.
[CLICK]
Risk-based initiatives will often come with compliance initiatives -- and will align risk and compliance programs with industry requirements and best practice methodologies. Those sources frequently have a component that will either tell you what you have to do, or provide guidance on what you should do.
For example, HIPAA has specific requirements and procedures they expect you to follow when securing protected health information and when reporting any kind of breach. The NIST Cyber Security Framework, on the other hand, provides guidance on what you could be doing. Often those sources will provide or suggest controls to have in place to meet those requirements.
The first step to take is to evaluate your controls and processes, and see if what you are doing makes sense. Are there any gaps between what you are doing and what you should be doing? Whatever is left from that is where we’ll want to spend some time to figure out if management and your compliance initiatives are ok with those gaps. Those gaps aren’t necessarily a bad thing, but unexplained gaps are where managers start to get excited.
Slightly unrelated to what we just talked about, but is a likely outcome from the decision made above, is the overall topic of threat management and response. So often this is thought of in two distinct buckets -- vulnerability management and incident response.
Regardless of how your organization views it, the concept of universally understanding what is a threat, what is a risk, and having a defined response method across the enterprise is essential to GRC in Information Security. There is a web between vulnerabilities, risks, incidents, compliance and overall governance that has to be present for that GRC initiative to work.
As a contributor, I know a lot about a sliver of why there is so much red in this report but probably don’t need to know if there was more or less red last month. Your manager likely does, and the senior leadership certainly does. That quantity and classification of risk each month will feed into what executives and Board members are going to want to see, and management will ask you questions before they send that report out. Because, like we said before, the Board expects immediate answers.

9. Info Sec Components
So now that we’ve got a basic understanding of the GRC concepts, what are the Info Sec components we can use to our advantage?
I like to break these components into something more digestible and think of it in terms of Technology, Processes and People. Each of those are separate and distinct components but is a common way people think of when applying ITIL concepts in an Information Security service offering.
[CLICK]

10. Technology
What existing toolsets have the information we will want to use?
CMDB – assets, applications, config validation
Tools – scanners, pen tests, Angry IP
Threat intelligence
How do I discover and evaluate their status?
What risks do I have because of them?
What technology tools do we have that work in our favor for GRC purposes?
As a consultant the first two things I’m most interested in are your CMDB and the tools used to identify security threats. Once I know what those tools are and the maturity of those tools we can move on to how you use those tools to perform your job.
But before I do that, it’s important at each step along this view of people, process, and technology that we keep the goal of GRC in mind. I’m looking to make informed decisions about my business operations by using what I have, and this technology portion is vital to discover all the things that are worth protecting. That is what’s going to tell me what risks I have as a result of knowing what management expects me to protect, and I’m using technologies to target them.
[CLICK]

11. Process
What action is taken from this and what decision does it help make?
Policies
Standards
Procedures
Are those steps repeated and predictable for all involved?
Where does that Technology data come from, any dependencies to obtain the data?
Now that I know what technologies I have, how do I use them? Now I need to define a process.
I’ve got a list of devices, assets, applications, IP ranges, etc. I’ve classified my data and know where it resides. I know the risks I face because I’ve got customer Personally Identifiable Information sitting on a database server outside of the DMZ that’s running Windows 08. Now what?
Using technology to my advantage, I can define a method that’s using those pieces of information and allows me to make informed decisions on when and how to act. That can come in the form of Policies, Procedures, Hardening Checklists -- whatever it may be my business unit needs in order to know and follow a routine so exceptions are not the rule.
What you see here is a process flow one of my clients implemented to manage web app findings. We’ll talking more about this client here in a couple minutes, but what you see here is a relatively straight forward approach that is a mature, repeatable process that provided the results they wanted.
Now, what I’m not showing you is their original approach. That’s for two reasons:
First, this screen is nowhere near large enough to show all the arrows, boxes, diamonds, and all those other Vizio boxes you see in process mapping.
Secondly, that diagram was only a diagram. It wasn’t followed because they didn’t have the technology to accomplish the process, and they did not have the people to pull it off.
[CLICK]

12. People Who has responsibility to create, deliver, and act on the data?
Who do they rely on?
Who ensures it is done?
Functions
Protect, monitor, maintain, recover
Roles
Application security, event monitoring, security governance, threat response
Accountability
Everyone
The third component is People. I find the people part of this equation the easiest part to talk about, but also something to evaluate more frequently than the tools you use or the processes you’ve implemented.
Identifying what functions exist, the role of those functions, and their accountability to the process -- the people aspect of GRC is the cornerstone of the program. It’s the engineer that knows even though the vulnerabilities found this last scan shot through the roof, they know the technology being used to perform those scans is not yet tuned enough to really rely on it yet.
It’s the analyst whose new role in reviewing SIEM log alerts is letting management know that after 4 failed log in attempts using the administer password, we’ve got an issue and we need to act now. Functions and roles are always going to be defined. Understanding who is accountable for those roles and spelling out the shared reliance is where the applied use of technologies and process will make that GRC program effective.
[CLICK]

13. Employing GRC GRC Compliance IT Operations Governance
Understand how the industry, the Board, and management expects us to function
Communicate guidance and allow operations the flexibility on how to integrate
It would be nice if we actually knew what was done operationally and could focus our guidance appropriately
GRC
IT Operations
We know what we protect and its current level of protection. We tell the people who we’ve been told are responsible for those things
We also know what isn’t protected or has no one responsible for it.
We wish it was easier to know we are protecting is what we should
Governance
Knows what should be protected and to what extent, based on what we use it for.
Rely on others to tell us when it doesn’t meet expectations, and get it corrected as long as it doesn’t affect our ability to operate.
Hope to find an easy way to operate without getting permission from others before taking action.
Security Operations
Continually evaluate threats and risks present that could prevent us from meeting management’s goals
Share roll-up information to provide management insights for decision making on matters that could impact objectives
Work with management to gauge the likelihood of meeting operational goals, but are met with resistance when identifying potential hazards to the organization
How do we employ GRC. Your organization will have business units with their own opinions about what you should be focusing on, and why you should listen to their point of view. Staying with the concept of managing vulnerabilities as our focus, I’ve called out four different departments or roles who have their own point of view on the matter.
[CLICK]
From the security operations side, they are going to continually evaluate the security threats and day to day risks from the business unit they support. Their role in letting management know about past, current, and the future state of security is vital for senior management to make decisions. But, when those figures don’t align with the business goals, the security team will face resistance. They can soften that resistance by speaking from the GRC perspective -- using facts about risk impact and the effects of non-compliance on business operations instead of the quantity of unpatched vulnerabilities.
The IT operations team should be working pretty close with security operations since they are probably the team telling security what should be protected and to what extent. However, they also know what security operations aren’t paying attention to. It makes their life easier if they just don’t mess with those things because it works fine and they don’t have time to jump through those hoops. It’s then just a matter of time before that comes back to hurt that data center manager when the system is breached.
The compliance team, maybe your audit department, will know what the industry and management is expecting from us all. They will hopefully provide you with some guidance on what you could be doing, but may struggle with understanding what you really do in operations. They could help by using their broad enterprise level knowledge, but only if you let them in.
And finally governance. This role is likely to know management’s expectations on how things should be protected. Since they are often an oversight function, they will rely on others to tell them when security expectations are not met. At the end of the day, if they can further understand the operations environment they can make it easier for them to act with that governance point of view in mind so IT operations doesn’t run the risk of begging for forgiveness later for the sake of not aligning with the governance plans everyone is expected to follow.
Certainly there is a lot in play here, and moving pieces with no one person, manager or executive in charge of all of it. But that’s the point. Each one of these groups is dependent upon another and is a service provider to someone else. They have important information to share but if it’s not aligned to the goals of the team and organization… why would they stop to adopt it?
By employing GRC elements those business units share a common language and allow others to benefit from their expertise. This leads to better collaboration and communication between them, creates efficiencies they all benefit from and further strengthens the program. Using what they know and are responsible for, and listening to what the other teams are really needing is where adoption and value is seen when employing each one of these GRC components.

14. GRC Ecosystem
The GRC ecosystem we see organizations operate is typically divided among seven disciplines. Risk, Compliance, Audit, Business Continuity, Incident, Information Security and Vendor. Those disciplines are reflected as applications in the Keylight Platform, which is the GRC tool created by LockPath.
This diagram gives just a few examples of how relationships from information security, risk, and audit is all stored and managed in their respective applications. It’s then shared across the platform and with other Keylight applications to give you that holistic view of compliance and the risk that currently exists.  This helps you then make critical decisions based on how those risks impact your business specifically.
[Click]
11/14/2018

15. Use Case Examples
Simple risk-based decisions to make Vulnerability Management more effective
Linking Identity Management to a GRC platform
Monitoring and managing Digital Risk
Now that we’ve set the stage with some business context, let’s take a look at some emerging processes within the domain of GRC.
[CLICK]

16. Risk-based decision making in Vulnerability Management
Challenges for a leading research institution
Speed to Act
Scan start to vulnerability assignment days
Vulnerability remediation 1.5 hours per system
1.5 FTE’s needed per 100 systems for IS tasks
Prioritization
15 System owners and 20 IT Custodians offered guidance
32 Department defined and agreed on priorities
Exceptions cannot become rule for 5,000 faculty
Those accountable for 800 servers expected a framework
So let’s talk about some real world challenges and results for a university-based research institution. The University of Chicago, and their CISO for the Biosciences Division, had taken over a team that was very understaffed for the responsibilities they were charged with.
Essentially their responsibility was, and still is, to protect the networks that grant-funded teams use to perform research. These networks, and devices on them, are set up with little-to-no oversight from a security perspective. This caused the CISO to mostly be in react mode to whatever he found when he went to look at them.
When you are constantly on your heels, under resourced, and over allocated, what can you use to level the playing field in vulnerability and device management? They found an advantage in not always reacting by using technology to increase efficiency and making use of the GRC information they had available to them.
As I mentioned, the CISO did not have the luxury of controlling device security or even having control over when a device came on board.
[CLICK]
When they would perform a device scan it would take them 5-7 days to even assign a device to a person outside the Biosciences Security team.
Beyond those 5-7 days, they could count on spending an hour and a half with each vulnerability, per system, that required attention.
So with the effort spent on scoping a vulnerability scan, evaluating the outcomes, reviewing the required actions, the remediation and closure took over an hour. When they look at the time investment, it took a person and a half for every 100 systems to perform all of the Information Security tasks they were charged with. They had to focus on prioritizing their efforts, one of the simplest tools available for risk management.
Their first step was to get the people who were responsible for those systems on board with what the CISO was tasked with. Their CISO had no tools to collect and distribute information, and no control over what these system owners and custodians put on their networks. But what he could do is make sure they knew the impact vulnerabilities would have on them.
Regulatory requirements and grant requirements were very much top of mind for the multiple college Deans who funded these networks. While the system owners and custodians spoke the same language of governance, the school departments and deans could understand the risk and compliance portion of the conversation as it meant the potential for having their funding pulled out from under them.
With those elements generally agreed upon, the CISO established a value proposition for the overall university. With 800 servers and faculty who could be bringing up a device on network at any point in time, Information Security will not allow exceptions to be the common response to managing threats. They all had a role in the prioritization of efforts and would not allow lack of controls to derail the goal of improving effectiveness of their vulnerability management program.
That is a lot of challenges, and certainly is very narrow window of an overall Information Security program and initiatives. But what was the payoff of their actions and what role did GRC and the tools they used play in that outcome?

17. Results with a GRC Platform
Respond With Defined Purpose
Assign immediately – 100% assignment
Effort on action, not analysis – 77% decrease
Efficiency and distribution of tasks
Adopt and Implement For Everyone
Solve problems that need a solution
Adopt activities that align with needs
Stakeholders help prioritize, then stop
Context and reason are required for adoption
First, they moved their CMDB to a GRC platform and included system owners and custodians. They were able to assign all vulnerabilities almost instantly.
Next, they put controls in place to require key ownership information for each device. Any device without essential ownership information was treated as a rogue and was immediately escalated to system owners to investigate. This was an immediate win for the CISO.
By using a GRC platform to implement and manage these two changes, Biosciences was able to refocus their efforts when taking action on threats. That 90 minutes they previously spent on reviewing vulnerabilities was reduced by 77% to less than 30 minutes due to automation based on the ownership information now captured in their GRC platform. They had the power to actually do their job of securing the technology the organization used, instead of continually asking, “Is this yours?” “Is this yours?” “Is this yours?”
But none of that was really possible or sustainable if the process they wanted, the controls they needed, and the outcome they were looking for wasn’t solving a problem that needed a solution.
The CISO could have taken several other paths to reach the same end point. But it wouldn’t have been a sustainable governance program without buy-in from stakeholders in the form of system owners and custodians. If the CISO chose to focus on threats that were not of a high enough risk to those who owned them, their compliance program would not have lasted any longer than the Dean trying to get the CISO out of his office.
Overall, the methodology they put in place wasn’t ground breaking, but was exactly what needed to be done and was accomplished for the right reasons. Technology was previously present, but it wasn’t effective because it wasn’t tuned with people and processes.
Adoption of the GRC initiatives the CISO put in place were key. And part of the reason they worked so well for Biosciences was they used a tool that housed those common elements of a GRC program. The combination of a GRC platform, plus the focus on people and process, were all necessary to capture, share, and report those vital governance, risk, and compliance elements.
[CLICK]

18. Linking Identity Management to GRC platforms
Challenges within Identity Management domain
Data integration within GRC solution
Risk-based access control
Evidence support for exception and incidents
Visibility to threats and vulnerabilities related to critical data and system access
Link access/identify information to a risk register
Link access to incident/exception management process
Reporting and metrics (threats and vulnerabilities) for critical IT assets
The mass deployment of Identity Management platforms has created a number of InfoSec activities to be improved upon with a GRC platform.
[CLICK]
We continue to work with our service and technology partners in this domain, and a number of use cases are showing up on the whiteboard. As an example, here are three problem areas within the Identity Management space:
Risk-based access control – standalone identity management systems do not have the ability to use a risk methodology to manage access – apps, systems, etc.
Evidence support for exceptions and incidents -- when exceptions are approved and incidents are recognized, standalone IM does not share this with the organization --- a potential problem for compliance
Threats and vulnerabilities related to data and system access --- reporting capabilities in standalone IM can be limited and do not pull in the context to identify threats/vulns correlated against critical IT assets

19. Monitoring and managing Digital Risk
Customer privacy breach at a financial institution
Dark Web Intelligence
Dark web threat intel reveals someone selling access to high net worth accounts
Seller further revealed to be a bank employee
High risk incident – response failure tied to major financial, legal and brand damage
GRC Processes to the Rescue
Incident tracking and response
Linking incident information to risk
Linking controls to support remediation and compliance
Targeted reporting
We work with a number of technology content providers in the SIEM market. An emerging sector on our radar for collaboration relates to monitoring and managing Digital Risk. Unlike traditional SIEM which stresses intel within the organization perimeter, Digital Risk management focuses on scanning data sources within the open, deep and dark web to protect a company’s business, brand and reputation. Sources ranging from WWW, dark web, IRC, P2P, FTP, mobile app stores, social media, code sites, paste sites. Findings in these sources can tie back to a number of enterprise risks such as cyber threats, infrastructure exposure, brand exposure, third party risk, data loss, physical security, and VIP exposure.
[CLICK]
This is an example of an actual incident through the findings of leading a Digital Risk management platform. In this case, an external scan for a bank discovers that potentially one of its employees is offering access to high net worth individual accounts. These types of events set off a broad set of investigative questions and a chain of processes depending upon a company’s GRC processes. Incident tracking and response and its corresponding workflows is an obvious one. Other value-added processes supported by GRC would include tying the incident to the company’s risk profile, ie. its risk register. The investigation in this event correlated the user access. Were there sufficient controls in place? If not, there’s a need to design and test a new/update a control and then link that control back to the risk register to support risk mitigation tasks.

20. Questions? Tony Rock LockPath VP, Business Development lockpath.com
Corporate address:
6240 Sprint Parkway, #100
Overland Park, KS 66211
LockPath
lockpath.com
@LockPath