Blog

"You need a pen test. This is a vulnerability assessment. Have you considered Red Team testing?"

You might have been told this by a regulatory examiner, your IT vendor, a senior partner, a Board member, or read it in an article. It's a common statement in the penetration testing space these days and with good reason. The scope and methodology of penetration tests is not standardized or regulated, so each provider can create their pen test service as they see fit. This puts more responsibility on you, the customer, to determine if they are meeting your needs.

In this article:

We covered these topics in our webinar Choosing Pen Tests & Real-Life Horror Stories. In this webinar we discussed:

  • The different types of penetration tests available
  • The pros and cons of different penetration tests
  • How to choose the best penetration test for your organization
  • Stories of real-world exploits
  • How to make the most of your penetration testing budget


What is Penetration Testing?

Many terms are used to describe penetration testing…

Red Team, Physical Intrusion, Gray Box Testing, Phishing, Reconnaissance, Privilege Escalation, Precision Strike, War Dialing, Black Box Testing, Social Engineering, Capture the Flag, Web Application Testing, Purple Team, White Box Testing, Blue Team, Pivoting, Internal Testing, External Testing

They overlap, they conflict, they can be misleading.

What is Penetration Testing?


So, what is pen testing?

Whether it's physical, logical, or human, pen testing shows you how an attacker would look at your organization. They look for holes and possibilities to disrupt the way you work.

Penetration testers look for holes and vulnerabilities that could disrupt the way you work.

According to the FFIEC IT Exam Handbook for financial institutions, there are many types of penetration tests . . . and management should determine the level and types of tests employed to ensure effective and comprehensive coverage.* The regulators are giving you the responsibility for figuring out what level and type of pen test you need.

So, what terms mean something, and what is terminology fluff? What should you look for when determining the pen test you need and what vendor to use?

Choosing and understanding penetration test vendors and knowing the terminology is important. Our aim in this article is to help remove some of the mystery around pen testing and help you feel confident in determine the best solution for your company.


What type of Pen Test do you need?

What is the type or level of penetration testing that you need?
Let's go back to the regulation:
"A penetration test subjects a system to real-world attacks selected and conducted by the testers." - FFIEC IT Exam Handbook, Information Security Booklet, Sep 2016 (emphasis added)

Essentially you are choosing what you want tested, you are not telling them how you want them to test it. That should be up to the penetration tester. The reason is, the penetration tester should have the expertise to know what the attackers are doing, and they are going to choose the real-world attacks that the attackers would choose. They have done the research, gone through the certifications and the training to know what types of methods to use. So it's important to know you're not telling them how to do the test, you're telling them what you want tested.

You figure out WHAT you need tested and the penetration tester will figure out HOW to test it.

Here is a simple definition of penetration testing that doesn't use any of the fancy marketing terms. Let's start here.

At its core, penetration testing should show you how an attacker would see you and describe specific attacks they would choose to use against you. That means you don't need to tell the pen testers HOW to do the testing. You just need to tell them WHAT to test and ensure their METHODOLOGY meets your needs and keeps you safe.

So, how do you determine WHAT you need?


Start with a Risk Assessment

When done correctly, a risk assessment will inform you of what you need to do for security testing.

Let's use an example to illustrate. Here is a simple risk assessment.

Simple Risk Assessment

  • What attacks do we hear about from IT, in the news, etc.?
    • Phishing!
    • Ransomware
    • Website attacks
  • What assets do those attacks target for us?
    • Employees
    • Corporate email and perimeter defenses
    • Web servers
  • What testing do we need?
    • Email social engineering for ALL employees
    • Internet perimeter testing for ALL of our public IP addresses

In this sample risk assessment, we are showing that as a company that offers services via the Internet our top concern is cybersecurity; but more specifically, we are concerned with phishing, ransomware, and website attacks.

So how do those threats apply to us? Phishing relies on our employees to click a link or open an attachment, so testing our people is important. Ransomware is typically introduced from the outside, so our corporate email defenses and perimeter defenses, such as firewalls, are important. Website attacks target our webservers directly, so those are also important targets.


Translate your Risk Assessment

After you perform a risk assessment, you will need to translate the results to answer the questions "What" to test and "Why" test it. The penetration test company will figure out "How" to test it.

For our sample risk assessment illustrated above, here is what we would choose:

  1. What to test? — Internet exposed systems
    Why test it? — These are our most exposed systems. They are what our attackers are going to hit first.
  2. What to test? — Employee responses to social engineering, because our employees are the ones who will protect us from phishing attacks.
    Why test it? — Phishing attacks are frequent and successful. They are hurting other people and happen all the time.

TIP: Test against common attacks. Attackers stick with what works. We're tempted to say "It's so common, let's look for the next big thing instead." Attackers will stick with what works as long as it works. So if you're hearing about things in the news, like ransomware and you're worried about it, then that is a valid threat to test against. It will continue to happen until it's no longer profitable for the attacker.

Test against common attacks. Attackers stick with what works as long as it works.

Whether your risk assessment is a formal or informal process is not as important as the results. You need to identify the areas where you are exposed, where your most critical assets are, and where attacks are most likely to occur. These decisions come from knowing your organization and knowing what types of attacks are common. We see these attacks in the news and other places all the time.


Determine the testing you need

Going back to our simple risk assessment example, we can take the assets we identified in the first step and translate them into the type of testing we need. In this case, we decided on email social engineering for all employees and Internet perimeter testing for all of our public IP addresses.

Be specific!

It is important to be very specific when communicating to your penetration testing company what type of testing you want performed. In a minute, we will look at what could happen if we don't communicate clearly.


Choosing a Pen Test Provider

Now that we know what we want to test, we need to define the scope of the testing. Do we want to test just our web servers or our entire Internet exposure? Do we want to test a specific group of employees or are we specifically concerned about a certain department that performs risky tasks – maybe they initiate wire transfers for our company.

In this example, we will define the scope as:

  • All public IP addresses
  • All employees

TIP: Include ALL external IP addresses, active and inactive. You never know when an inactive IP address might become active. Mistakes and misconfigurations happen and attackers are looking for them.

This scope can be modified over time. Maybe we want to test all employees the first time and then focus on a risky department the next time.

What can happen if you don't communicate clearly?

Check out what happened when pen testing services were requested by Iowa State Court Officials. As reported in this news article, the scope of testing was defined as "test the security of the court's electronic records . . . through various means." Not specific enough! It only defined an asset, not what the organization was worried about or what they wanted tested. The result: two pen testers were arrested in Adel, Iowa for attempting to physically break into the court house. The State's response: "[we] did not intend, or anticipate, those efforts to include the forced entry into a building."

In other words, if we want our employees tested against phishing and our Internet perimeter tested against a remote attacker, we don't want the pen testers to do this to our front door:

Unrelated to the Iowa incident, this gentlemen is well-known for his pen testing of physical controls, but would you want this sort of testing when you are concerned about ransomware coming in through phishing emails?


Set the Rules of Engagement

The final step in our pen test selection process is to set the boundaries for our pen testers to follow. Remember that we get to choose WHAT they target, but they get to choose the attacks that would be most effective – what the real attacker might choose. By settings boundaries on those attacks or rules of engagement, we can ensure the pen test won't go too far and cause harm.

In this step you will agree on:

  • What the pen testers WILL attempt
  • What the pen testers WON'T attempt

"The test mimics a threat source's search for and exploitation of vulnerabilities to demonstrate a potential for loss." - FFIEC IT Exam Handbook, Information Security Booklet, Sep 2016 (emphasis added)

Going back to our regulatory reference, these boundaries are stated as "demonstrating the potential for loss." Notice it doesn't say "demonstrating the loss," but rather the potential for loss. This is an important word to highlight because it identifies the need for pen test boundaries. We want our pen test firm to show us how an attack could happen and how it could negatively impact our organization, but we don't want them to go so far as to actually cause loss or have a significant negative impact.

Here's an example set of the rules of engagement that CoNetrix will use. Because we typically test live, operational systems, we put certain rules into place to make sure the testing stays within bounds.

Rules of Engagement
  • Do no harm. It's not a good penetration test if the penetration test company leaves you more vulnerable than you were when you started. What would that look like? If they went into a system and they installed malware and left that malware sitting there and didn't tell you they installed it. That malware may be opening a door to the internet that you didn't have before. If the pen testers create new exposure, then it would leave you worse off than when you started.
  • No significant customer impact. You don't want customers calling in saying: "I can't get into my internet banking account," "I can't log in to this website," "the website is down." The penetration test company needs to be very aware of who your customers are and how they use your systems. They need to make sure that everything they do does not impact the customer. Some tests can't be performed unless there is some customer impact. How would a penetration company handle that? The way it should go is: 1) Identify the vulnerability and the potential exploit for that vulnerability. 2) Contact the customer and let them know about it. If they would like us to perform the exploit, inform them it may cause some downtime and it might affect their customers. 3) Coordinate with the customer on when to perform the exploit testing. Maybe we do it after hours. Or it may be they are great with just knowing the vulnerability exists and don't need the exploit performed due to the possible negative impact.
  • No unplanned operational impact. A penetration test company may discover that your system or website is extremely vulnerable to a certain kind of denial of service attack. If exploited, it could be taken down for hours on end. That's great to know, but the penetration test company should not exploit that vulnerability without coordinating with you first. That would cause unplanned operational impact and now your IT department is scrambling and your customers or your internal staff are upset because they can't do their job or access your services.
  • Limited system recovery time/money. This is an important one and not always obvious. If you're not careful, a penetration tester that is not very good at what they're doing could say "well, we could do this and they would just have to restore from backup". That's easy for the penetration tester to say, but they aren't the ones who have to do the work to restore from backup. A lot of times restoring from backup can be a complicated process and can take a while. It might cost a lot of time and money, and that may not be obvious to a penetration tester. Just having a dedicated person to go recover a system can be a big impact to other projects and tasks you have going on. If an exploit is going to take significant effort or money to recover from, then that needs to be out of bounds, unless you have coordinated about it ahead of time.
  • Attempted exploits need to provide value. Penetration testing can be flashy and glamorous. It shows up in movies, TV shows, YouTube, etc. Make sure that the exploits that are being performed are providing value. Flashy and glamorous is fine for the movie screen, but real world pen testing must provide value to your company by helping improve your security posture.
  • If an exploit might break the rules, report the vulnerability. A penetration test company may say they found this vulnerability, but if exploiting it is going to break the rules, then it would be better to just report the vulnerability and say what needs to be fixed. It's better to do that than to cause your customers and staff a lot of grief. The vulnerability can be talked about and remediated without causing problems.

These are the rules of engagement we practice here at CoNetrix when performing penetration tests.


Evaluate a Pen Test Provider

So let's wrap up how to choose a pen test provider with some ways you can evaluate pen testers and then we'll move on to the fun stuff – the exploits!

  1. Know what you need tested and clearly communicate that in the project scoping and quoting process. We talked about identifying what you need tested. Make sure the pen test company's expertise matches with what you need tested. As we saw earlier, some pen testers excel in physical security testing. Others excel at Internet-based testing. Some are industry-specific such as SCADA pen testers. Make sure you find out what their strengths are.
  2. Make sure their report is understandable and well-organized. Many pen testers are great at successfully demonstrating attacks. After all, that's the fun part – the part that gets put into the movies. Buy many don't put as much effort in communicating what they did and how you can improve your defenses. Make sure the format of the report and the way information is communicated in the report is going to help you improve your security. Is it actionable for you and your IT/security staff?
  3. Check out their certifications on top of experience. Certifications are a great way of making sure a pen test company has the knowledge and skills necessary. Some examples include Certified Ethical Hacker (CEH), Offensive Security Certified Professional (OSCP), and any certification that shows they have knowledge of the area you need tested.
  4. Make sure the penetration test company will help you understand the report. We believe security testing is most useful when it is a partnership, not a stand-alone service. Ask how the pen test company will help you understand what the issue is and what you can do about it. Do they review their results with you? Do they provide remediation recommendations? Or do they drop a bunch of results on you and wish you good luck.

Phases of Pen Testing

So now let's talk about the fun side of pen testing—exploitation. It's good to know that exploitation is part of the process. Many times it is because of this process that a penetration test report may look like a vulnerability assessment. Every pen test process follows a similar process—identify how the target is exposed—identify vulnerabilities that could be attacked—exploit those vulnerabilities—report both the vulnerabilities and any successful exploits.
But what if no exploits were possible—at least not within the rules of engagement? In that case, the report would only identify vulnerabilities and could look a lot like a vulnerability assessment. But through your pen test selection process, you made sure the firm would exploit vulnerabilities when safe and possible and their documented methodology should reflect that approach.
Phases of Pen TestingOne of the best things you can do when evaluating a pen test company is ask them for examples of what they have done. See how they did it and whether you're comfortable with the things they are capable of doing.

One of the best ways to evaluate a pen test company is to ask for some examples of their successful exploits.

*FFIEC IT Exam Handbook, Information Security Booklet, Sep 2016
**This blog post is for information purposes only. Evaluate your risks before acting on any ideas presented in this article.


 

On Wednesday, November 14th, the Federal Financial Examination Council (FFIEC) released an updated version of the Business Continuity Management Booklet. One of the changes is related to business continuity and disaster recover exercises and tests. In the new booklet, the FFIEC redefines the testing methods and introduces more delineation between a BCP exercise and a BCP test.

What is a BCP Exercise?

According to the new booklet, "an exercise is a task or activity involving people and processes that is designed to validate one or more aspects of the BCP or related procedures" (p. 37). Each exercise can look different depending on the scope, goals, and objectives of the test. Some exercises can be discussion only (i.e. tabletop discussion) while others could be comprehensive (i.e. full-scale exercise).

What is a BCP Test?

The new booklet defines a test as a "type of exercise intended to verify the quality, performance, or reliability of system resilience in an operational environment" (p. 37). Tests typically focus on a system or set of systems. An example of a test might be verifying back on a server is functions or verifying recovery time objectives (RTOs) are acceptable for a system. The big difference according to the booklet is, "exercises address people, processes, and systems whereas tests address specific aspects of a system" (p. 38).

How are the testing methods different in the new booklet?

Examples of testing methods from the older 2015 Business Continuity Planning Booklet included (p. 18):

  • Tabletop Exercise Structured Walk-Through Test. "[The tabletop exercise structured walk-through tests] primary objective is to ensure that critical personnel from all areas are familiar with the BCP and that the plan accurately reflects the financial institution's ability to recover from a disaster."
  • Walk-Through Drill/Simulation Test. "A walk-through drill/simulation test is somewhat more involved than a tabletop exercise/structured walk-through test because the participants choose a specific event scenario and apply the BCP to it."
  • Functional Drill/Parallel Test. "Functional drill/parallel testing is the first type of test that involves the actual mobilization of personnel to other sites in an attempt to establish communications and perform actual recovery processing as set forth in the BCP."
  • Full-Interruption/Full-Scale Test. "In a full-scale test, a real-life emergency is simulated as closely as possible."

The new testing methods introduced in the 2019 Business Continuity Management Booklet map closely to its predecessor; however, they are renamed and have slight differentiators (pp. 42-44).

  • Full-Scale Exercise. "A full-scale exercise simulates full use of available resources (personnel and systems) prompting a full recovery of business processes."
  • Limited-Scale Exercise. "A limited-scale exercise is a simulation involving applicable resources (personnel and systems) to recover targeted business processes."
  • Tabletop Exercise. "A tabletop exercise (sometimes referred to as a walk-through) is a discussion during which personnel review their BCP-defined roles and discuss their responses during an adverse event simulation."
  • Tests. "Management uses tests to verify the quantifiable performance and reliability of system resilience."

What does this mean for me?

The new FFIEC guidance highlights the "people and processes" aspects of your organization's BCP. This is a shift in focus from the 2015 BCP booklet in which testing guidance more heavily emphasized testing IT systems and system components. This change can be seen in the definitions of the testing methods. Personnel are specifically included in all four of the "exercise" definitions whereas the definition of "tests" is only concerned with validating system resilience.

What hasn't changed is BCP exercises and tests are used to validate one or more aspects of an enterprise-wide BCP. Financial institutions should incorporate a variety of exercises and tests into their overall BCP test program in order to ensure the institution can restore operations and recover from business interruptions. While the test program will be different based on each institution's size and complexity, strong test plans include strategies to evaluate all aspects of the institution's BCP, including people and processes as well as IT systems.

Resources

For more information about the updated booklet, visit:

 


 

I was working with a Windows Surface where the user would open File Explorer from the taskbar and it would freeze.  The window showed the message "Getting Things Ready" and would never open.  
 
The first time I looked at this, I ended up deleting all of the user's quick access history thinking there was corruption somewhere.  This resolved the issue for about 3 weeks until it returned.
 
I was able to right click on the Windows logo, click run, and open C:\ with no issues loading the file explorer window.  Clicking on quick access had no issues, as long as I didn't open file explorer from the taskbar.
 
The fix for this is to open file explorer as previously mentioned to the C:\ through run command, go to view, and click options.  In the general tab is a drop down that says "Open File Explorer to: "Quick access" or "This PC".  
 
Changing the setting from "Quick access" to "This PC" resolved file explorer freezing when opened from the taskbar.
 

 

When removing unwanted Windows 10 Apps via Powershell scripts, the process for removing it for all users deletes the AppXPackages from C:\Program Files\WindowsApps. This is normally the intended process, however, most scripts used to remove these use shorthand names such as "Netflix" to find the package label of the appxbundle then using the full path found, delete it. The reason the shorthand is used is because every major release of Windows 10 (1809, 1903, etc) changes these packages. This shorthand method has at times removed packages unintentionally. In order to add the package back you need to find the .appxbundle and .xml of the exact version of Windows 10 you are using. An in place upgrade can be done to replace the missing packages, however, remotely that's not always a feasible/safe option.
 
Microsoft has a Windows 10 Inbox Apps ISO for each available Windows 10 version. These can be found on the Microsoft Volume Licensing Service Center. In order to reinstall the package use the following steps.
  • Mount ISO
    • Mount the ISO or UNC path with Packages to be added.
    • Open Powershell as Admin
    • Run powershell command: Add-AppxProvisionedPackage -Online -PackagePath <path to .appxbundle> -LicensePath <path to .xml>
      • Add-AppxProvisionedPackage -Online -PackagePath "D:\x86fre\Microsoft.WindowsCalculator_8wekyb3d8bbwe.appxbundle" –LicensePath "D:\x86fre\Microsoft.WindowsCalculator_8wekyb3d8bbwe.xml"
 

 

Recently I noticed the fingerprint reader on my T450s had stopped working. I cleaned it, rebooted my laptop (twice), and it still didn't work. I went to Device Manager and didn't see Biometric Devices or anything resembling Synaptics, so I started researching what the problem may have been. I saw a lot of suggestions such as modifying registry keys and such, but I avoid those steps without proper supervision. Eventually I finally found a solution that fixed my fingerprint reader issue. Go to Settings\Apps\Apps & Features\Search for Synaptics and then select Uninstall. After the reboot, my fingerprint reader was working again. I went into Device Manager and confirmed Biometric Devices was there again, and made sure the driver was updated.


 

We've all done it before — searched for instructions on something we feel like we should be able to do ourselves. Whether it's how to tie a bow tie, how to change your oil, or how to repair a smartphone, people are constantly looking to do things for themselves. Naturally there are tasks beyond our actual ability, but can you blame any of us for trying? We have the information, resources, and always the desire to save money. That being said, one of the things that is likely beyond DIY abilities is combating cyberattacks for your business.

There are a seemingly unlimited number of cybersecurity solutions created to help businesses protect the personal and financial information of their customers. These services are best supported by cybersecurity companies, but far too often business owners and IT managers look to buy the tools and attempt to do it themselves. But can you really learn everything you need to about technologies like SIEM and then defend against cyber-attacks?

This blog will explain why you not only need cybersecurity tools, but also cybersecurity vendors to provide you with effective solutions.

SIEM Systems Need Constant Management

Depending on the SIEM system, there are different approaches for cybersecurity monitoring and protection. No matter if the SIEM tool is made by Intel, IBM, or Fortinet, the overall goal of being notified of attackers is the same. However, one may have a larger range of coverage for devices and log types, while another may have a specific log manager that picks up different events. Whatever it may be, the solution will collect information and present an analysis, but to optimize your security there should be someone managing the system full-time.

Let's say you want to build a shed in your backyard to protect some equipment and toys from the rain, and you have a hammer, plenty of nails, wood, and a few other tools. Unfortunately, nothing will get done if you don't pick up the hammer. While it is great that you have the necessary tools and supplies, but you will never build a shed to protect your equipment and toys if no one is utilizing the tools. It is the same with these SIEM services, or tools — without full-time personnel, ideally from a professional cybersecurity company, you are at risk of missing critical notifications and real threats.

Why Cybersecurity is not a DIY Product

If you don't necessarily think this is the case and you feel confident that you'll be able to check up on the program every now and again, you might want to reconsider. There were 668 million breaches in the U.S. just last year alone (the year before, there were over 1.5 billion breaches); this means that over 668 million times confidential information was exposed without permission. Also, 38% of the world's cyberattacks are targeted at the United States. While we are legally required to secure our customers' information, these numbers alone highlight the magnitude of the problem and the necessity to invest in a solid cybersecurity company's services. With a constant attack from unseen sources, are you really all that confident that you'll be able to manage it all yourself?

Let's again assume you are determined in doing this all yourself. Are you proficient in programming Java or C/C++? Do you understand web application technologies? Linux operating systems? Telephony technologies (analog and Voice over IP)? Okay, well…maybe you don't but you can learn, right? If that is the case, are you planning on learning on the fly from a couple of online videos? We don't want to discourage you from learning, but we need to be realistic. Installing a SIEM program and then following a manual to figure out how to make everything work is about as easy as putting a 4th grader, who is just able to read decently well, into a college-level biology and expect them to do be successful. The information is right in front of them, but can you really expect that?

Maybe we aren't giving you enough credit and you actually do understand all of these things — if that is the case, good for you for sticking with this blog and reading all the way to here — but can you handle reading all the analyzed data for every device for your entire company every day? That's where the benefit of hiring a cybersecurity company to manage the entire SIEM system for you comes into play. Not only will you have a service that is customized to your business, but you will also have a team of experts constantly reviewing your system for dangerous activity. With just the SIEM tool at your disposition, you may be alerted when a breach is detected but what will you do from there? A Managed Security Provider like this will not only notify you but also assist with a solution.

The wisest approach when you are looking to improve your company's cybersecurity is to not only purchase one of the many tools that are on the market, but make sure you also have a cybersecurity company on your side providing you with all the support you need.


 

I was needing to add some interactive check boxes to a Word document, but found out that they only show up in the "Developer" menu, which does not show up by default in Word. To add the "Developer" tab menu, you must follow the following steps:

  1. Click the "File" drop down menu
  2. Click "Options" at the bottom of the menu
  3. Select "Customize Ribbon" on the left side of the dialog box that appears
  4. Choose "Main Tabs" from the "Customize the Ribbon" drop down menu
  5. Check the "Developer" box to enable it:

 

6. Then to add a checkbox, switch to the "Developer" tab and click the checkbox icon:


 

When a FortiGate is managed via FortiManager, administering the FortiGate outside of FortiManager can cause the configuration to become out of sync. While updating an SSL certificate used for VPN access on a FortiGate for a customer, I found that I was unable to create a certificate signing request from FortiManager. After doing some research, I found a Fortinet cookbook article that explains that the certificate must be requested and the certificate request completed from the FortiGate itself, even if the device is managed via FortiManager. To complete this process, do the following:
  • Login to the FortiGate in read-write mode
    • Create a certificate signing request on the FortiGate
    • Download the certificate signing request from the FortiGate
    • Submit the certificate signing request to the certificate authority
    • Download the issued certificate from the certificate authority
    • Import the certificate on the FortiGate to complete the certificate signing request
  • Login to FortiManager
    • Select the FortiGate in Device Manager and go to the "System: Dashboard" page
    • In the "Configuration and Installation Status" pane, click the "Revision History" (four horizontal lines) icon on the "Total Revisions" line
    • Click the "Retrieve Config" button
    • The current configuration, including the new certificate, will be retrieved.
    • The certificate should now be able to be used in configurations managed in FortiManager
If you are deleting the old certificate, you will need to write the config to the FortiGate from FortiManager so that it is no longer using the old certificate. After the old certificate is no longer in use, you can login to the FortiGate in read-write mode and delete the old certificate. After the old certificate is deleted, you will need to repeat the "Retrieve Config" operation.
 
The Fortinet cookbook article explaining this process can be found at https://kb.fortinet.com/kb/documentLink.do?externalID=FD35142

 

Unauthorized individuals have accessed nonpublic information, who do you notify? Whether it be documents discovered in dumpsters that should have been shredded, ransomware holding information hostage, or a tornado that blew files all over the county.

Definition of Information

Before we can determine appropriate action, we must first understand what exactly we are talking about. In this instance, we are talking about personally identifiable information (PII). The definition appears to be standard across all industries, whether it be financial industries, healthcare industries, or beyond. However, although information is considered publicly available information, once it is combined with consumer information for a service or product it then becomes nonpublic personal information.

U.S. Department of Homeland Security

The U.S. Department of Homeland Security released a factsheet that defines personally identifiable information (PII).

PII is any information that permits the identity of an individual to be directly or indirectly inferred, including any information which is linked or linkable to an individual. Some PII is not sensitive, such as that found on a business card. Other PII is Sensitive PII, which if lost, compromised, or disclosed without authorization, could result in substantial harm, embarrassment, inconvenience, or unfairness to an individual.

That definition leaves room for some interpretation, and even some misinterpretation if we are not careful.

Gramm-Leach-Bliley Act (GLBA)

In 1999, Congress adopted the Gramm-Leach-Bliley Act (GLBA) to provide a framework for the financial services industry. When talking about nonpublic information, we often reference GLBA; however, it is actually only a small section of the act. Title V of the GLBA defines nonpublic information as follows;

Nonpublic personal information may include individual items of information as well as lists of information. For example, nonpublic personal information may include names, addresses, phone numbers, social security numbers, income, credit score, and information obtained through Internet collection devices (i.e., cookies).

I like to think about it this way, what information of mine do I not want to be disclosed? When classifying data, do you assess the legal implications for information being disclosed? What about the reputational implications if customer or consumer information is disclosed?

Considerations for your Incident Response Plan

Avoiding notification does not guarantee the preservation of reputation. Notification paired with action already taken or to be taken can be used in your favor. No notification and the public learning of the disclosure from another source will rarely work to your advantage.

Your Incident Response Plan needs to include metrics to help determine what action is necessary. To help with that, address the following questions within your plan:

  • What types of information disclosure requires notification?
  • Who is notified?
    • Does your regulatory agency require notification? When in doubt, reach out to your regulatory agency. I know, I know! I hear the grumblings and eye rolls as I type this. Contrary to popular opinion, your examiners' sole purpose in their regulatory life is not to make you miserable, but rather to collaborate with you and help. Build that relationship with them.
    • Does law enforcement require notification? It is a good practice to notify law enforcement (local, FBI, Secret Service, etc.). They may not be able to assist with your incident; however, it is possible they are working on a case that is linked to yours.
    • Do service providers and/or insurance providers require notification? Some service agreements and insurance policies have very specific notification requirements identified. Make sure these are identified in your Incident Response Plan so you do not miss those in a time of crisis.
    • Do customers require notification? In 2005, the FFIEC agencies jointly issued a guidance, Response Programs for Unauthorized Access to Customer Information and Customer Notice. In it, it clearly states if customer information has been accessed in an unauthorized manner, timely customer notification is required.
    • Do consumers and/or the public require notification? What if rather than customers it was consumers affected? Individual notification may not be feasible. Assess the impact of notification, or lack thereof, to determine if notification is warranted. A consumer could be a potential customer, and the notification could be what sways them one way or the other.

As you are developing your notification procedures in your Incident Response Plan, keep in mind notification timing. For example, law enforcement may need to you hold off on notifying customers and/or the general public for investigative purposes. Your insurance policy may dictate they be notified prior to any other action taken. Make sure your plan outlines these, and are reviewed as part of your Incident Response testing.

In the End

According to the Identity Theft Resource Center, in July 2019 alone, 104,546,381 sensitive records were exposed due to varying types of breaches. This indicates information disclosure is inevitable, which means having a strong notification strategy is necessary.


 

On May 24, 2019, Fortinet published an advisory stating that certain versions of their FortiOS software are vulnerable to a path traversal attack which allows an attacker to download system files through specially crafted HTTP requests. The vulnerability is only present when the SSL VPN service is enabled – either web-mode or tunnel-mode. The vulnerable FortiOS versions and the corresponding patched versions are:

  • FortiOS 6.0.0 to 6.0.4
    • Patched version: 6.0.5 or above
  • FortiOS 5.6.3 to 5.6.7
    • Patched version: 5.6.8 or above
  • FortiOS 5.4.6 to 5.4.12
    • Patched version: 5.4.13 (upcoming)

CoNetrix Security Penetration Test engineers have confirmed this vulnerability can be used to download usernames and passwords from FortiGate devices. The usernames and passwords can then be used to establish an SSL VPN connection which would give an attacker access to internal networks and systems.

CoNetrix strongly recommends all customers ensure the patched versions of FortiOS listed above are installed on all Fortinet devices that have the SSL VPN service enabled.

CoNetrix Technology customers with managed service agreements have already been updated to the FortiOS version to protect against the vulnerability.

References:
https://fortiguard.com/psirt/FG-IR-18-384
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-13379