
FortiGates not connecting to FortiGuard

When a secondary public IP address is utilized for VPN connections, the configuration of an IPSEC VPN versus an SSL VPN is quite different. For an IPSEC VPN, it's as easy as turning flipping a switch and selecting the IP address:
For SSL VPN it takes a couple of steps: First a Virtual IP (VIP) has to be created that points the primary IP at the secondary IP. Additionally include port forwarding for the SSL port to be utilized:
Second, an IPv4 policy needs to be created using the WAN interface for both incoming and outgoing, with the destination being the VIP:
Windows 10 upgrades can fail for a number of reasons. Digging through the setup logs to determine the reason it failed can be frustrating and confusing. Microsoft has an application called "setupdiag" that will help you determine specifically what caused the upgrade to fail by parsing through the logs for you.
https://docs.microsoft.com/en-us/windows/deployment/upgrade/setupdiag
When doing maintenance on an Exchange server environment configured with a DAG, one of the things that you have to be aware of is how to temporarily remove one of the servers from the DAG before you disrupt any of the Exchange services (i.e. reboot) so that it doesn't inadvertently cause a failover of your databases or make some databases unavailable. Microsoft wrote a blog post a while back talking about the proper way to place an Exchange server into maintenance mode and it's a bit clunky - https://blogs.technet.microsoft.com/nawar/2014/03/30/exchange-2013-maintenance-mode/
Fortunately, there's a script readily available that takes care of most of this for you, including failing over the database to another Exchange server if needed. Located in 'Program Files\Microsoft\Exchange\V15\Scripts', take a look at the StartDagServerMaintenance.ps1 and StopDagServerMaintenance.ps1 scripts (and the RedistributeActiveDatabases.ps1 script. Running the script is simple, just pass the server name that you're starting or stopping maintenance on to their respective scripts and let PowerShell take care of the rest! Easy, no?
Well, sorta. You see, for a few versions now (including Exchange 2013 and Exchange 2016), the StartDagServerMaintenance.ps1 script has a typo in it – specifically the part of the script that actually pauses the node in the cluster. In the parameters, Microsoft has set "$pauseClusterNode" equal to "$false" instead of "$true".
Left alone like this, the cluster node will never be paused and potentially could cause issues when you reboot, not to mention that when you run the StopDagServerMaintenance.ps1 script, you'll receive a warning that "Call-ClusterExe: cluster.exe did not succeed" meaning it didn't do anything. Just change that parameter to "$true" and you're good to go.
"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:
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.
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 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?
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
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.
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:
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.
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.
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:
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? |
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:
"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
|
These are the rules of engagement we practice here at CoNetrix when performing penetration tests.
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!
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.One 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.
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).
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).
Examples of testing methods from the older 2015 Business Continuity Planning Booklet included (p. 18):
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).
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.
For more information about the updated booklet, visit:
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.