4 Tips for Prioritizing Metrics

There are three phases to setting up a security metrics program. First, you must collect the data, analyze it and finally report your findings. The Collection phase involves installing sensors (Zeek, Commercial IDS/IPS, vulnerability scanners, etc.). The Analysis phase uses tools such as ServiceNow, Remedy, Crystal Reports, etc. The Reporting phase is the process of creating workbooks (weekly, monthly, yearly) and a set of Operational, Incident and Compliance reports. Your target audiences include your boss, your boss’ boss, IT manager peers, security team, your Board, internal audit, CFO/COO and units involved with regulatory compliance. Matt Tolbert gave a talk in 2007 on Security metrics that resonated with me. Here are some notes I took from his talk for prioritizing security metrics. A good metrics reporting package should include:

1. Operational. Examples of these reports include helpdesk tickets completed, security project status, # of security scans completed and their results, inventory of hardware or software connected to your network. The target audience includes your boss, IT manager peers, and your security team.

2. Incident. These are the number of reported security incidents and their status such as success/failure, financial and reputational impact, “after action reports”, legal status. The target audience is your boss, your boss’ boss and your Board of Directors/Trustees.

3. Compliance. These metrics show how effective your security controls, services and training are in complying with whatever security or data standards your organization has to be in compliance.  The target audience includes your boss, your boss’ boss, internal audit and units involved with regulatory compliance. 

4. Executive. These metrics are similar to the Compliance metric but they also show the value of the security controls, services and training you’ve installed. They should also show areas that need improvement as well as showing progress to meeting the organization’s business goals.

Tolbert suggested 4 benefits from building a security metrics program. These metrics can help:

1. Provide budget and staffing justification for expansion

2. See what risks your organization really faces

3. See what risks your organization will face long and short tem

4. Gauge the effectiveness of your team(s) effectiveness in meeting your security control requirements.

There are a number of good resources on building a security metrics program. Matt Tolbert’s 2007 “Effective Security Metrics” presentation is a great summary.  Andrew Jaquith’s book “Security Metrics: Replacing Fear, Security and Doubt” is another good resource. It’s one of my “bibles” of security metrics. The Educause “Effective Security Metrics: A Guide to Effective Security Metrics” ( https://www.educause.edu/focus-areas-and-initiatives/policy-and-security/cybersecurity-program/resources/information-security-guide/toolkits/effective-security-metrics ) has good high level points to setting up a security metric framework regardless of your industry sector.

Motorcycle Riding and Being A CISO

 I was checking out some YouTube videos and ran across this one with Michael Jordan, Charles Barkley and Oprah Winfrey. Towards the end of the video, Michael talks about being a defensive driver if you ride a motorcycle. "You have to be really focused and see the traffic ahead", says Jordan.  He then takes a dig at Charles.  Check out https://www.youtube.com/watch?v=t_Q1k2r2yao.

 

I've ridden bicycles almost all of my life and motorcycles for the last third of my life. When I'm on the bike (either type), I am looking ahead to see what traffic patterns are there and trying to anticipate how I can maneuver through those patterns safely and efficiently. My nephew and I used to play a game when he was younger. We'd be in the mall and the challenge was to walk through a crowd from point A to B without missing a step or stopping because someone stepped in front of you. You had to watch the traffic flow and make your best guess on  where and when an opening would occur.

 

This is one of the things a CISO or security architect should practice. You want to look at threat intel, network traffic or attack patterns and chart a course of action based on your past knowledge as well as your ability to guess what will happen next. Sure, sometimes you guess wrong but you use that knowledge to improve your prediction capability. Sound like machine learning? Probably.

 

Next time you ride a bicycle or motorcycle, see if you ride defensively by looking ahead and anticipating the next action that can happen. Take that skill and apply it to designing your security architecture.

Is Protecting Admin Privs on Endpoints Still Relevant?

 

The post-pandemic WFH (Work From Home)  model should force us to reevaluate the effectiveness of our security architectures. The most common reason for wanting administrative privileges on a device is that the local IT support can't install needed software when it's required by the business. I ask my SANS students how long it takes to install a software package for a business unit. The answers range from 1-2 weeks to 6 or more months because of a software review process. 

Admin privileges on endpoints: 

I want to emphasize that I'm NOT talking about administrative privileges on Active Directory or some other central management (Kaseya, Solarwinds, etc.)  domain accounts. I'm talking about local accounts and accounts on standalone computers. 

Is the "User having (local/standalone) admin privileges on a computer" as bad a security risk as people say it is? I emphasize the term "local/standalone" admin accounts. I think it is not.  Why? 

  

1) in the old days, having admin privileges on a multi-user system was a big deal. If you were in administrator/root mode and your account got owned, the consequence of that breach would impact ALL of the users on that system.  For large multiuser systems, that could be hundreds to thousands of users.  I understand why there was concern about the administrative/root accounts being secure. For servers that provide a service to multiple remote (to the server) users, it makes sense to restrict admin privileges on the server(s).

  

 2) In today's BYOD world, users are admin/root and general users simultaneously. There usually is only user per device. The impact of an admin/root failure is limited to the individual.   Phishing, ransomware attacks are just as damaging regardless of the entity that triggered the attack being a general user or admin level account.  Smartphones, tablets, etc. have merged the admin and general privilege levels into a single account so it makes no sense to "restrict" admin privileges on those devices today. You can't enforce that.  

  

What about high risk data exposure? Such data exposures can happen in either admin/root or general user mode. For most of the hits I've seen over the years, the damage was done regardless of the privilege level of the account involved.

  

It comes down to training. I've said in a previous blog entry that a poorly trained sysadmin is one of the greatest threats to an organization's data and infrastructure. Organizations should require a minimum amount of training for employees who want administrative privileges on a device. 

Time to Train -

 "Excuse me, sir. How do I get to Carnegie Hall?"

"Practice, Practice, Practice."

I've always said that a poorly trained sysadmin is one of the greatest threats to any organization's infrastructure. The military training module may seem archaic and cumbersome but it is effective. There is a significant amount of investment in creating an effective training program. I believe the correct technical description is "it ain't cheap".  Organizations that fail to train their technical and general user staff in basic or advanced IT security practices are doomed to suffer multiple failures. 

I'm not going to dive into pedagogy (can't help but giggle everytime I hear that word) or the merits of a good training program. Too much has been said on those topics. Instead, I'm going to present my idea of a training roadmap here:

 Here we have 3 main training tracks:

• Technical track - the target audiences are system administrators, developers, IT Security analysts/architects. These training programs are designed to enhance your staff's technical knowledge.
• Awareness track - the target audiences are your general staff, management. These training programs are designed to make your workforce aware of the laws, regulations, best practices for handling your organization's sensitive data. In addition, these programs show your staff the different types of physical and cyber attacks they may see and how to respond to these threats.
• User (How-to) track - this training program teaches your staff how to use the day to day tools of your business. It covers things like how to:
• use Microsoft Office, Adobe Acrobat tools
• use graphical design tools
• use collaboration tools
• use in-house tools
• use external software or hardware products.

There needs to be a blend of externally developed training materials (SANS Secure the Human, Skillsetsonline, LinkedIn Learning, etc.) and "local" training for in-house applications.

Take a look at the above roadmap and I would like to hear your suggestions on how to improve or implement the roadmap.

Resilience Is the Key to a Successful Defensive Strategy

The main mission of any CISO is not to prevent breaches of their infrastructure, rather, it's to safeguard you organizations' sensitive data and identity. I've said many time in the past that there are no device breach notifications but there are plenty of data breach notification laws. There are many ways to protect data and identity like encryption, monitoring outbound traffic, increasing user awareness, multi-factor authentication. These are important things but they are a means to achieve a goal. Resilience is the key to a sound defensive strategy. Here are some thoughts.

1. We play defense not offense. 95% of companies hire cybersecurity people to defend their company from cyberattacks. They don't hire them to attack other sites. That's what the remaining 5% do. However, to play good defense, one must know how to play good offense. In other words, a Blue Team should have strong Red Team skills.
2. One must accept the fact that a breach will happen regardless of whatever controls are in place. The old defensive strategy of building a "wall" to keep the bad guys out has failed. While there are many variants of the now popular Zero Trust Network philosophy, there are 2 key points that must be in place:
1. The network is hostile.
2. Data and identity are the new borders
3. The key to a successful defensive strategy is resilience not prevention.  A sound resilience strategy is key to recovery.

Resilience 

I could give the Webster's dictionary definition of resilience but let me give you an example.

Ransomware is one of the destructive attacks that has affected a large number of organizations and people recently.  It's been around since 1989 but what made it popular was the introduction of cryptocurrency as the payment mechanism. For example, the Virginia State prescription monitoring database was hit with a ransomware attack in 2009 and the attackers demanded a $10M ransom. The state didn't pay and restored from backups. There was a disruption of service, some loss of data but the service recovered. Collecting the $10M in small bills requires a bunch of duffel bags and every LEO in the planet watching those bags to see who collects them. 

This incident convinced me that the best defense against ransomware attacks is not "prevention", rather, it is "recovery". Take the time to carefully align file permissions with need-to-access requirements of the business. This is a difficult step. It may limit ransomware damage by limiting the files the malware can access.

 

A good backup strategy is the best defense in this case. A system gets hit with ransomware, you wipe it, patch it, restore your data from good backups and then move on with your business. A good resilience strategy should include these steps:

• find your sensitive data. Consolidate it into something like a data lake. 
• Map where your sensitive data goes within your network borders as well as outside your borders. 
• Backup this data lake by taking snapshots, doing old school incremental backups and store the backups offline in a read-only mode. For example, NetApp devices allow the creation of a read-only snapshot.
• Test your recovery processes frequently.

The old RFC 1244 "Site Security Handbook" describes two defensive strategies: "Protect and Proceed" and "Pursue and Prosecute".  It set the following conditions for each of these approaches:

 

Protect and Proceed

      1. If assets are not well protected.

      2. If continued penetration could result in great

         financial risk.

      3. If the possibility or willingness to prosecute

         is not present.

      4. If user base is unknown.

      5. If users are unsophisticated and their work is

         vulnerable.

      6. If the site is vulnerable to lawsuits from users, e.g.,

         if their resources are undermined.

   Pursue and Prosecute

      1. If assets and systems are well protected.

      2. If good backups are available.

      3. If the risk to the assets is outweighed by the

         disruption caused by the present and possibly future

         penetrations.

      4. If this is a concentrated attack occurring with great

         frequency and intensity.

      5. If the site has a natural attraction to intruders, and

         consequently regularly attracts intruders.

      6. If the site is willing to incur the financial (or other)

         risk to assets by allowing the penetrator continue.

      7. If intruder access can be controlled.

      8. If the monitoring tools are sufficiently well-developed

         to make the pursuit worthwhile.

      9. If the support staff is sufficiently clever and knowledgable

         about the operating system, related utilities, and systems

         to make the pursuit worthwhile.

      10. If there is willingness on the part of management to

          prosecute.

                                             Figure 1. Protect and Proceed vs Pursue and Prosecute

My ransomware scenario's recovery process is an implementation of requirement listed in RFC 1244 - " "Attempts will be made to actively interfere with the intruder's processes, prevent further access and begin immediate damage assessment and recovery." 

This is an example of resilience. Andy Greenberg's book "Sandworm" has a chapter dedicated to resilience. Dan Geer's essay "A Rubicon" is another example of the importance of resilience. Creating an "parallel" network universe addresses interdependency issues and allows for a quick recovery.

We should certainly spend funds on detection tools but the bulk of present-day defenses should be focused on how we recover from an attack. Resilience processes such as backups,  monitoring and disrupting outbound traffic to questionable sites are examples of a good resilience strategy. 

You're going to get breached at some point in time. How fast you recover can limit the damage done to your business processes. 

References

https://assets.documentcloud.org/documents/4366740/Geer-Webready-Updated.pdf

https://tools.ietf.org/html/rfc1244

https://mysupport.netapp.com/NOW/public/eseries/sam_archive1150/index.html#page/GUID-8538272A-B802-49D9-9EA2-96C82DAD26A2/GUID-F6C0C512-F196-4008-97AE-EA06EE4D32F6.html

RDP Security Tip and other Infographics

 Thanks to Thomas Roccia for this great resource he created. It's at https://medium.com/@tom_rock/security-infographics-9c4d3bd891ef. I think you'll find these graphs to be particularly useful in any presentation you do. 

We've been asked a lot about Remote Desktop security given the WorkFromHome (WFH) situation we're in during the pandemic. It is a serious problem and here's a great infographic from Thomas' site. 

Academic Freedom and IT Security - They Do Work Well Together

 I was a member of a panel on Cyber Hygiene that was sponsored by the SANS Institute today. My good buddies, Tony Sager and Russell Eubanks were also on the panel. 

An attendee asked me about the challenge of balancing IT Security practices vs. the cherished Academic Freedom (AF) issue. I responded that IT has to stop being the Department of NO and go out and listen and learn how researchers do their thing. Only then should they decide on a path that supports rather than hinders their research. It's harder to take the time to meet and learn how end users actually do things  given the multitude of tasks most IT people need to perform in their normal course of duties. Understanding how and why your end users do things allows you to design and build a more efficient IT Security program and architecture. Short term pain eventually leads to long term gain. Taking the time to understand how your end users actually use your IT services will actually lessen the amount of time you have to spend outside of your normal duties in the long term. 

It was a great question and it got me thinking about the issue a little more and hence, this blog entry. I've been working in EDU IT for 45 years now and here are some musings on this balancing challenge.

I went on a motorcycle ride and got to thinking more about the question while I was riding through the mountains. It occurred to me that there should be no conflict between IT security and AF principles.  IT Security practices should enhance and protect AF. One complements the other. 

First, let's try to define "academic freedom" for the purpose of this blog. Here are some definitions that I'll use as my foundation. Academic Freedom is defined as:

1. a scholar's freedom to express ideas without risk of official interference or professional disadvantage. "we cannot protect academic freedom by denying others the right to an opposing view" (Oxford Dictionary)

2. Academic freedom means that both faculty members and students can engage in intellectual debate without fear of censorship or retaliation. (https://www.insidehighered.com/views/2010/12/21/defining-academic-freedom)

3. Teachers are entitled to full freedom in research and in the publication of the results, subject to the adequate performance of their other academic duties. Teachers are entitled to freedom in the classroom in discussing their subject, but they should be careful not to introduce into their teaching controversial matter that has no relation to their subject. (https://www.aaup.org/issues/academic-freedom/professors-and-institutions)

After reading these definitions, I tried to see what the conflict was between IT practices and Academic Freedom (AF). Frankly, I saw more opportunities for IT practices to support, secure and protect AF. All 3 of the above definitions emphasize the right of the academic community to discuss freely any topic without the fear of censorship or retaliation. Looking at this from the IT Security point of view, here are some threat scenarios to AF in the online world.  A sample threat would be attacks against the Confidentiality, Integrity and Availability (CIA) aspects of AF.

For example, let's look at censorship. DOS/DDOS attacks,  domain blocking, confiscation of servers or endpoints are examples of availability attacks. Unauthorized modification of topics/data is an example of an integrity attack. Doxing is an example of a confidentiality attack. 

There are existing IT Security practices that can mitigate the effects of these classes of attacks.  Availability threats such as DOS/DDOS attacks can be deflected. Domain blocking can be addressed. Good file permission strategies along with good backups, file integrity tools can mitigate integrity attacks. Hunting down doxxers, online "bullies" can be done using techniques such as OSINT and log analysis to protect  individuals from harassment or retaliation.

Sound IT Security practices can and should be done to further advance academic freedom. I think the supposed conflict between IT Security and AF is not the big issue everyone outside of the EDU world thinks it is. 

To the webinar attendee who asked me the question of balancing IT Security practices with Academic Freedom, let me say IT Security practices should support academic freedom by designing procedures for protecting one's right to academic freedom. It should never interfere with that core business process.

This is my short answer to this question. I'd like to hear your opinions on this matter.

8/8/2020