Daily Archives: November 11, 2020

Finding a USB Drive

Be very careful of any lost USB drives you may find (such as in the parking lot or local coffee shop) or USB drives you are given at public events, like conferences. It is very easy for these devices to be infected with malware. Never use such devices for work, use only authorized devices issued to you by work.

Avionics Safety and Secured Connectivity: A Look at DO-326A/ED-202A, DO-355 and DO-356

One of the major improvements that the avionics industry is undergoing is an Internet of Things (IoT) upgrade. And this is inevitably affecting how airlines approach aircraft safety. From the beginning, safety has been paramount to the aviation industry. But while it is a welcome innovation, the incorporation of IoT devices in aircraft comes with […]… Read More

The post Avionics Safety and Secured Connectivity: A Look at DO-326A/ED-202A, DO-355 and DO-356 appeared first on The State of Security.

Two New Chrome 0-Days Under Active Attacks – Update Your Browser

Google has patched two more zero-day flaws in the Chrome web browser for desktop, making it the fourth and fifth actively exploited vulnerabilities addressed by the search giant in recent weeks. The company released 86.0.4240.198 for Windows, Mac, and Linux, which it said will be rolling out over the coming days/weeks to all users. Tracked as CVE-2020-16013 and CVE-2020-16017, the flaws were

Changes to Microsoft Security Bulletins

For those that have been in the industry for more than a couple of years, you will remember when Microsoft retired the very powerful and well-documented security bulletins back in 2017. At the time, we felt that it was a severe reduction in the availability of information; Microsoft was suddenly communicating much less information. Yesterday, […]… Read More

The post Changes to Microsoft Security Bulletins appeared first on The State of Security.

ITWC adds two new events to its flagship program

Events provide actionable insights from experts, peers ITWC, Canada’s largest content provider serving the IT industry, is pleased to announce the 2021 schedule for its flagship events and signature awards programs. “We have all seen unprecedented change in 2020,” said ITWC President Fawn Annan. “I am proud to say ITWC turned those challenges into opportunities…

The post ITWC adds two new events to its flagship program first appeared on IT World Canada.

Exploring the Exploitability of “Bad Neighbor”: The Recent ICMPv6 Vulnerability (CVE-2020-16898)

Exploring the Exploitability of “Bad Neighbor”: The Recent ICMPv6 Vulnerability (CVE-2020-16898)

At the Patch Tuesday on October 13, Microsoft published a patch and an advisory for CVE-2020-16898, dubbed “Bad Neighbor”, which was undoubtedly the highlight of the monthly series of patches. The bug has received a lot of attention since it was published as an RCE vulnerability, meaning that with a successful exploitation it could be made wormable. Initially, it was graded with a high CVSS score of 9.8/10, though it was later lowered to 8.8.

In days following the publication, several write-ups and POCs were published. We looked at some of them:

The writeup by pi3 contains details that are not mentioned in the writeup by Quarkslab. It’s important to note that the bug can only be exploited when the source address is a link-local address. That’s a significant limitation, meaning that the bug cannot be exploited over the internet. In any case, both writeups explain the bug in general and then dive into triggering a buffer overflow, causing a system crash, without exploring other options.

We wanted to find out whether something else could be done with this vulnerability, aside from triggering the buffer overflow and causing a blue screen (BSOD)

In this writeup, we’ll share our findings.

The bug in a nutshell

The bug happens in the tcpip!Ipv6pHandleRouterAdvertisement function, which is responsible for handling incoming ICMPv6 packets of the type Router Advertisement (part of the Neighbor Discovery Protocol).

The packet structure is (RFC 4861):

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|  Reserved |       Router Lifetime         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Reachable Time                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Retrans Timer                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Options ...
+-+-+-+-+-+-+-+-+-+-+-+-

As can be seen from the packet structure, the packet consists of a 16-bytes header, followed by a variable amount of option structures. Each option structure begins with a type field and a length field, followed by specific fields for the relevant option type.

The bug happens due to an incorrect handling of the Recursive DNS Server Option (type 25, RFC 5006):

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Length    |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Lifetime                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
:            Addresses of IPv6 Recursive DNS Servers            :
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Length field defines the length of the option in units of 8 bytes. The option header size is 8 bytes, and each IPv6 address adds additional 16 bytes to the length. That means that if the structure contains n IPv6 addresses, the length is supposed to be set to 1+2*n. The bug happens when the length is an even number, causing the code to incorrectly interpret the beginning of the next option structure.

Visualizing the POC of 0xeb-bp

As a starting point, let’s visualize 0xeb-bp’s POC and get some intuition about what’s going on and why it causes a stack overflow. Here is the ICMPv6 packet as constructed in the source code:

As you can see, the ICMPv6 packet is followed by two Recursive DNS Server options (type 25), and then a 256-bytes buffer. The two options have an even length of 4, which triggers the bug.

The tcpip!Ipv6pHandleRouterAdvertisement function that parses the packet does two iterations over the option structures. The first iteration does simple checks such as verifying the length field of the structures. The second iteration actually parses the option structures. Because of the bug, each iteration interprets the packet differently.

Here’s how the first iteration sees the packet:

Each option structure is just skipped according to the length field after doing some basic checks.

Here’s how the second iteration sees it:

This time, in the case of a Recursive DNS Server option, the length field is used to determine the amount of IPv6 addresses, which is calculated as following:

amount_of_addr = (length – 1) / 2

Then, the IPv6 addresses are processed, and the next iteration continues after the last processed IPv6 address, which, in case of an even length value, happens to be in the middle of the option structure compared to what the first iteration sees. This results in processing an option structure which wasn’t validated in the first iteration. 

Specifically in this POC, 34 is not a valid length for option of the type 24, but because it wasn’t validated, the processing continues and too many bytes are copied on the stack, causing a stack overflow. Noteworthy, fragmentation is required for triggering the stack overflow (see the Quarkslab writeup for details).

Zooming out

Now we know how to trigger a stack overflow using CVE-2020-16898, but what are the checks that are made in each of the mentioned iterations? What other checks, aside from the length check, can we bypass using this bug? Which option types are supported, and is the handling different for each of them? 

We didn’t find answers to these questions in any writeup, so we checked it ourselves.

Here are the relevant parts of the Ipv6pHandleRouterAdvertisement function, slightly simplified:

void Ipv6pHandleRouterAdvertisement(...)
{
    // Initialization and other code...

    if (!IsLinkLocalAddress(SrcAddress) && !IsLoopbackAddress(SrcAddress))
        // error

    // Initialization and other code...

    NET_BUFFER NetBuffer = /* ... */;

    // First loop
    while (NetBuffer->DataLength >= 2)
    {
        BYTE TempTypeLen[2];
        BYTE* TempTypeLenPtr = NdisGetDataBuffer(NetBuffer, 2, TempTypeLen, 1, 0);
        WORD OptionLenInBytes = TempTypeLenPtr[1] * 8;
        if (OptionLenInBytes == 0 || OptionLenInBytes > NetBuffer->DataLength)
            // error

        BYTE OptionType = TempTypeLenPtr[0];
        switch (OptionType)
        {
        case 1: // Source Link-layer Address
            // ...
            break;

        case 3: // Prefix Information
            if (OptionLenInBytes != 0x20)
                // error

            BYTE TempPrefixInfo[0x20];
            BYTE* TempPrefixInfoPtr = NdisGetDataBuffer(NetBuffer, 0x20, TempPrefixInfo, 1, 0);
            BYTE PrefixInfoPrefixLength = TempRouteInfoPtr[2];
            if (PrefixInfoPrefixLength > 128)
                // error
            break;

        case 5: // MTU
            // ...
            break;

        case 24: // Route Information Option
            if (OptionLenInBytes > 0x18)
                // error

            BYTE TempRouteInfo[0x18];
            BYTE* TempRouteInfoPtr = NdisGetDataBuffer(NetBuffer, 0x18, TempRouteInfo, 1, 0);
            BYTE RouteInfoPrefixLength = TempRouteInfoPtr[2];
            if (RouteInfoPrefixLength > 128 ||
                (RouteInfoPrefixLength > 64 && OptionLenInBytes < 0x18) ||
                (RouteInfoPrefixLength > 0 && OptionLenInBytes < 0x10))
                // error
            break;

        case 25: // Recursive DNS Server Option
            if (OptionLenInBytes < 0x18)
                // error

            // Added after the patch - this it the fix
            //if (OptionLenInBytes - 8 % 16 != 0)
            //    // error
            break;

        case 31: // DNS Search List Option
            if (OptionLenInBytes < 0x10)
                // error
            break;
        }

        NetBuffer->DataOffset += OptionLenInBytes;
        NetBuffer->DataLength -= OptionLenInBytes;
        // Other adjustments for NetBuffer...
    }

    // Rewind NetBuffer and do other stuff...

    // Second loop...
    while (NetBuffer->DataLength >= 2)
    {
        BYTE TempTypeLen[2];
        BYTE* TempTypeLenPtr = NdisGetDataBuffer(NetBuffer, 2, TempTypeLen, 1, 0);
        WORD OptionLenInBytes = TempTypeLenPtr[1] * 8;
        if (OptionLenInBytes == 0 || OptionLenInBytes > NetBuffer->DataLength)
            // error

        BOOL AdvanceBuffer = TRUE;

        BYTE OptionType = TempTypeLenPtr[0];
        switch (OptionType)
        {
        case 3: // Prefix Information
            BYTE TempPrefixInfo[0x20];
            BYTE* TempPrefixInfoPtr = NdisGetDataBuffer(NetBuffer, 0x20, TempPrefixInfo, 1, 0);
            BYTE PrefixInfoPrefixLength = TempRouteInfoPtr[2];
            // Lots of code. Assumptions:
            // PrefixInfoPrefixLength <= 128
            break;

        case 24: // Route Information Option
            BYTE TempRouteInfo[0x18];
            BYTE* TempRouteInfoPtr = NdisGetDataBuffer(NetBuffer, 0x18, TempRouteInfo, 1, 0);
            BYTE RouteInfoPrefixLength = TempRouteInfoPtr[2];
            // Some code. Assumptions:
            // PrefixInfoPrefixLength <= 128
            // Other, less interesting assumptions about PrefixInfoPrefixLength
            break;

        case 25: // Recursive DNS Server Option
            Ipv6pUpdateRDNSS(..., NetBuffer, ...);
            AdvanceBuffer = FALSE;
            break;

        case 31: // DNS Search List Option
            Ipv6pUpdateDNSSL(..., NetBuffer, ...);
            AdvanceBuffer = FALSE;
            break;
        }

        if (AdvanceBuffer)
        {
            NetBuffer->DataOffset += OptionLenInBytes;
            NetBuffer->DataLength -= OptionLenInBytes;
            // Other adjustments for NetBuffer...
        }
    }

    // More code...
}

As can be seen from the code, only 6 option types are supported in the first loop, the others are ignored. In any case, each header is skipped precisely according to the Length field.

Even less options, 4, are supported in the second loop. And similarly to the first loop, each header is skipped precisely according to the Length field, but this time with two exceptions: types 24 (the Route Information Option) and 25 (Recursive DNS Server Option) have functions which adjust the network buffer pointers by themselves, creating an opportunity for inconsistencies. 

That’s exactly what is happening with this bug – the Ipv6pUpdateRDNSS function doesn’t adjust the network buffer pointers as expected when the length field is even.

Breaking assumptions

Essentially, this bug allows us to break the assumptions made by the second loop that are supposed to be verified in the first loop. The only option types that are relevant are the 4 types which appear in both loops, that’s also why we didn’t include the other 2 in the code of the first loop. One such assumption is the value of the length field, and that’s how the buffer overflow POC works, but let’s revisit them all and see what can be achieved.

  • Option type 3 – Prefix Information
    • The option structure size must be 0x20 bytes. Breaking this assumption is what allows us to trigger the stack overflow, by providing a larger option structure. We can also provide a smaller structure, but that doesn’t have much value in this case.
    • The Prefix Length field value must be at most 128. Breaking this assumption allows us to set the field to an invalid value in the range of 129-255. This can indeed be used to cause an out-of-bounds data write, but in all such cases that we could find, the out-of-bounds write happens on the stack in a location which is overridden later anyway, so causing such out-of-bounds writes has no practical value.

      For example, one such out-of-bounds write happens in tcpip!Ipv6pMakeRouteKey, called by tcpip!IppValidateSetAllRouteParameters.
  • Option type 24 – Route Information Option
    • The option structure size must not be larger than 0x18 bytes. Same implications as for option type 3.
    • The Prefix Length field value must be at most 128. Same implications as for option type 3.
    • The Prefix Length field value must fit the structure option size. That isn’t really interesting since any value in the range 0-128 is handled correctly. The worst thing that could happen here is a small out-of-bounds read.
  • Option type 25 – Recursive DNS Server Option
    • The option structure size must not be smaller than 0x18 bytes. This isn’t interesting, since the size must be at least 8 bytes anyway (the length field is verified to be larger than zero in both loops), and any such structure is handled correctly, even though a size of 8-bytes is not valid according to the specification.
    • The option structure size must be in the form of 8+n*16 bytes. This check was added after fixing CVE-2020-16898.
  • Option type 31 – DNS Search List Option
    • The option structure size must not be smaller than 0x10 bytes. Same implications as for option type 25.

As you can see, there was a slight chance of doing something other than the demonstrated stack overflow by breaking the assumption of the valid prefix length value for option type 3 or 24. Even though it’s literally about smuggling a single bit, sometimes that’s enough. But it looks like this time we weren’t that lucky.

Revisiting the Stack Overflow

Before giving up, we took a closer look at the stack. The POCs that we’ve seen are overriding the stack such that the stack cookie (the __security_cookie value) is overridden, causing a system crash before the function returns.

We checked whether overriding anything on the stack can help achieve code execution before the function returns. That can be a local variable in the “Local variables (2)” space, or any variable in the previous frames that might be referenced inside the function. Unfortunately, we came to the conclusion that all the variables in the “Local variables (2)” space are output buffers that are modified before access, and no data from the previous frames is accessed.

Summary

We conclude with high confidence that CVE-2020-16898 is not exploitable without an additional vulnerability. It is possible that we may have missed something. Any insights / feedback is welcome. Even though we weren’t able to exploit the bug, we enjoyed the research, and we hope that you enjoyed this writeup as well.

How to Successfully Transition Software from PA-DSS to the PCI Secure Software Standard


On 28 October 2022, the Payment Application Data Security Standard (PA-DSS) program will officially close. In this blog, Jake Marcinko, PCI SSC Senior Manager, Emerging Standards, shares how PA-DSS compares to its successor, the PCI Secure Software Standard, a standard within the PCI Software Security Framework (SSF); and Tracey Harrington, PCI SSC Manager, Certification Programs, offers key timelines and suggestions on how to prepare your organization to make the transition.

Empowering employees to securely work from anywhere with an internet-first model and Zero Trust

Like many this year, our Microsoft workforce had to quickly transition to a work from the home model in response to COVID-19. While nobody could have predicted the world’s current state, it has provided a very real-world test of the investments we have made implementing a Zero Trust security model internally. We had about 97 percent of our workforce at the peak successfully working from home, either on a Microsoft issued or personal device. 

Much of the credit for this success goes to the Zero Trust journey we started over three years ago. Zero Trust has been critical in making this transition to a work-from-home model relatively friction-free. One of the major components to our Zero Trust implementation is ensuring our employees have access to applications and resources regardless of their location. We enable employees to be productive from anywhere, whether they’re at home, a coffee shop, or at the office.  

To make this happen, we needed to make sure most of our resources were accessible over any internet connection. The preferred method to achieve this is through modernizing applications and services using the cloud and modern authentication systems. For legacy applications or services unable to migrate to the cloud, we use an application proxy service which serves as a broker to connect to the on-premise environment while still enforcing strong authentication principles.  

Strong authentication and adaptive access policies are critical components in the validation process. A big part of this validation process included enrolling devices in our device management system to ensure only known and healthy devices are directly accessing our resources. For users on devices that are not enrolled in our management system, we have developed virtualization options that allow them to access resources on an unmanaged device. One of the early impacts of COVID-19 was device shortages and the inability to procure new hardware. Our virtualization implementation also helped provide secure access for new employees while they waited for their device’s arrival. 

The output of these efforts, combined with a VPN configuration that enables split tunneling for access to the few remaining on-premises applications, has made it possible for Microsoft employees to work anywhere in a time when it is most critical. 

Implementing an internet-first model for your applications

In this blog, I will share some recommendations on implementing an internet-first approach plus a few of the things we learned in our efforts here at Microsoft. Because every company has its own unique culture, environments, infrastructure, and threshold for change, there is no one-size-fits-all approach. Hopefully, you will find some of this information useful, even if only to validate you are already on the right path. 

Before I jump in, I just want to mention that this blog will assume you’ve completed some of the foundational elements needed for a Zero Trust security model. These include modernizing your identity system, verifying sign-ins with multi-factor authentication (MFA), registering devices, and ensuring compliance with IT security policies, etc. Without these protections in place, moving to an internet-first posture is not possible. 

As previously mentioned, your apps will need to be modernized by migrating them to the cloud and implementing modern authentication services. This is the optimal path to internet accessibility. For apps that can’t be modernized or moved to the cloud (think legacy on-premises apps), you can leverage an app proxy to allow the connection over the internet and still maintain the strong authentication principles. 

Secure access via adaptive access policies

 Once your apps are accessible via the public internet, you will want to control access based on conditions you select to enforce. At Microsoft, we use Conditional Access policies to enforce granular access control, such as requiring multi-factor authentication, based upon user context, device, location, and session risk information. We also enforce device management and health policies to ensure the employee comes from a known and healthy device once they have successfully achieved strong authentication. 

 Depending on your organization’s size, you might want to start slow by implementing multi-factor authentication and device enrollment first, then ramping up to biometric authentication and full device health enforcement. Check out our Zero Trust guidance for identities and devices that we follow internally for some additional recommendations. 

 When we rolled out our device enrollment policy, we learned that using data to measure the policy’s impact allowed us to tailor our messaging and deployment schedule. We enabled “logging mode”, which let us enable the policies and collect data on who would be impacted when we moved to enforcement. Using this data, we first targeted users who were already using compliant devices. For users that we knew were going to be impacted, we crafted targeted messaging alerting them of the upcoming changes and how they would be impacted. This slower, more measured deployment approach allowed us to monitor and respond to issues more quickly. Using this data to shape our rollout helped us minimize the impact of significant policy implementation. 

Start with a hero application

Picking your first application to move out to the public internet can be done in a few different waysDo you want to start with something small and non-critical? Or perhaps you want to “flip the switch” to cover everything at once? We decided to start with a hero application that proved it works at scale. Office 365 was the obvious choice because it provided the broadest coverage since most employees use it daily, regardless of what role they are in. We were confident if we could implement Office 365 successfully, we could be successful with most of our portfolio. 

Ultimately, it will boil down to your environment, threshold for support engagements, and company culture. Choose the path that works best for you and push forward. All paths will help provide valuable data and experience that will help later 

Prioritize your remaining apps and services

Prioritizing the apps and services you modernize next can be challenging, especially without granular visibility into what employees are accessing in your environment. When we began our journey, we had theories about what people were accessing but no data to back it up. We built a dashboard that reported actual traffic volumes to applications and services still routing to on-premises applications and services to provide the visibility we lacked. This gave us much-needed information to help prioritize apps and services based on impact, complexity, risk, and more.  

We also used this dashboard to identify which application or service owners we needed to coordinate with to modernize their resources. To coordinate with these owners, we created work items in our task tracking system and assigned the owner a deadline to provide a plan to either modernize or implement a proxy front end solution. We also created a tracking dashboard for all these tasks and their status to make reporting easier.  

We then worked closely with owners to provide guidance and best practices to drive their success. We conduct weekly office hours where application and service owners can ask questions. The partnership between these application and service owners and the teams working on Zero Trust helps us all drive towards the same common goals—frictionless access for our employees. 

A quick note on what we learned through the dashboard—the on-premises applications and services people were still accessing were not what we were expecting. The dashboard surfaced several items we were unaware people were still using. Fortunately, the dashboard helped remove a layer of fog we were unaware even existed and has been invaluable in driving our prioritization efforts. 

As I mentioned at the beginning of this blog, every company is unique. As such, how you think about Zero Trust and your investments might be different than the company across the street. I hope some of the insight provided above was helpful, even if it is just to get you thinking about how you would approach solving some of these challenges inside your own organization 

 To learn more about how Microsoft IT (Information Technology), check out IT ShowcaseTo learn more about Microsoft Security Solutionsvisit our websiteBookmark theSecurity blogto keep up with our expert coverage on security matters. Also, follow us at@MSFTSecurityfor the latest news on cybersecurity.  

The post Empowering employees to securely work from anywhere with an internet-first model and Zero Trust appeared first on Microsoft Security.

The Security Failures of Online Exam Proctoring

Proctoring an online exam is hard. It’s hard to be sure that the student isn’t cheating, maybe by having reference materials at hand, or maybe by substituting someone else to take the exam for them. There are a variety of companies that provide online proctoring services, but they’re uniformly mediocre:

The remote proctoring industry offers a range of services, from basic video links that allow another human to observe students as they take exams to algorithmic tools that use artificial intelligence (AI) to detect cheating.

But asking students to install software to monitor them during a test raises a host of fairness issues, experts say.

“There’s a big gulf between what this technology promises, and what it actually does on the ground,” said Audrey Watters, a researcher on the edtech industry who runs the website Hack Education.

“(They) assume everyone looks the same, takes tests the same way, and responds to stressful situations in the same way.”

The article discusses the usual failure modes: facial recognition systems that are more likely to fail on students with darker faces, suspicious-movement-detection systems that fail on students with disabilities, and overly intrusive systems that collect all sorts of data from student computers.

I teach cybersecurity policy at the Harvard Kennedy School. My solution, which seems like the obvious one, is not to give timed closed-book exams in the first place. This doesn’t work for things like the legal bar exam, which can’t modify itself so quickly. But this feels like an arms race where the cheater has a large advantage, and any remote proctoring system will be plagued with false positives.

Patch Tuesday (November 2020): Microsoft Releases Fix for Zero-Day Vulnerability Found in Windows

The monthly security updates known as Patch Tuesday have been recently published by Microsoft. This time, 112 software flaws across a wide variety of products ranging from Windows to Microsoft Teams have been patched. The most significant one updated this month is the zero-day vulnerability found in Windows which has also been spotted being exploited […]

The post Patch Tuesday (November 2020): Microsoft Releases Fix for Zero-Day Vulnerability Found in Windows appeared first on Heimdal Security Blog.

Cyber Security Today – Headache for older Android phones users, encryption debate rises again and beware of a fake Microsoft Teams update

Headaches for older Android phones are coming, encryption debate rises again and beware of a fake Microsoft Teams update.

The post Cyber Security Today - Headache for older Android phones users, encryption debate rises again and beware of a fake Microsoft Teams update first appeared on IT World Canada.

Hashtag Trending – Apple’s M1 chip; Canada preps to spend big on network infrastructure; Coping with pandemic burnout

Apple’s new M1 chip has been announced, Canada is preparing to spend big on developing network infrastructure, and how to cope with pandemic burnouts.

The post Hashtag Trending - Apple's M1 chip; Canada preps to spend big on network infrastructure; Coping with pandemic burnout first appeared on IT World Canada.

Over 2800 e-Shops Running Outdated Magento Software Hit by Credit Card Hackers

A wave of cyberattacks against retailers running the Magento 1.x e-commerce platform earlier this September has been attributed to one single group, according to the latest research. "This group has carried out a large number of diverse Magecart attacks that often compromise large numbers of websites at once through supply chain attacks, such as the Adverline incident, or through the use of

Microsoft Releases Windows Security Updates For Critical Flaws

Microsoft formally released fixes for 112 newly discovered security vulnerabilities as part of its November 2020 Patch Tuesday, including an actively exploited zero-day flaw disclosed by Google's security team last week. The rollout addresses flaws, 17 of which are rated as Critical, 93 are rated as Important, and two are rated Low in severity, once again bringing the patch count over 110 after

Build Your 2021 Cybersecurity Plan With This Free PPT Template

The end of the year is coming, and it's time for security decision-makers to make plans for 2021 and get management approval. Typically, this entails making a solid case regarding why current resources, while yielding significant value, need to be reallocated and enhanced. The Definitive 2021 Security Plan PPT Template is built to simplify this task, providing security decision-makers with an

Operation Tovar: What It Was and How A Key Botnet Was Eliminated

Over the past years, organized malware disruptions have grown in speed and prominence as more and more businesses and law enforcement entities fought together. As HeimdalTM Security has always advocated for building strong connections and working together as a community, throughout the years we’ve been involved in global anti-cyberthreat operations such as the No More […]

The post Operation Tovar: What It Was and How A Key Botnet Was Eliminated appeared first on Heimdal Security Blog.

What are the best cyber security training courses?

There has never been a better time to start a career in cyber security. Organisations’ reliance on technical solutions has only increased with the global switch to remote working, creating a huge demand for qualified personnel.

But it can be tricky knowing where to begin. Cyber security is a complex, multidisciplinary field, with varied opportunities depending on your skills and interests.

In this blog, we explain the best cyber security qualifications to help you get started.


Start with the basics and learn your trade

Those in the early stage of their careers should get as much practical experience as possible and look to achieve industry-standard qualifications.

A good place to start is the Certified GDPR Foundation Training Course or the Certified ISO 27001 ISMS Foundation Training Course.

Data protection and data privacy are at the core of cyber security, so it’s worth gaining a solid understanding of these issues.

The GDPR (General Data Protection Regulation) contains a detailed list of requirements that are designed to better protect the personal data of EU residents and give them more control over the ways their personal data is used.

No matter what area of cyber security you move into, you will almost certainly run into GDPR compliance at some point – whether that’s because you handle EU residents’ personal data or because you design or use systems intended to uphold its requirements.

ISO 27001, meanwhile, is the international standard for information security. Its best-practice approach enables organisations to address their security needs through an ISMS (information security management system).

This centralised approach can help organisations achieve GDPR compliance and streamline their data protection processes as a whole.

Many organisations across the globe either certify to ISO 27001 or use the framework to inform their information security practices, so anyone interested in work that involves handling sensitive information must be to be familiar with the Standard.


Do you need the technical stuff?

To advance in any cyber security field, you’ll need some technical expertise – but you don’t necessarily need a comprehensive understanding of programming or hacking.

You can become an IT specialist or manager if you’re familiar hardware, software, networks and applications – as well as the security threats associated with them.

For those who are interested in technical work, there are plenty of options. The easiest one to get into is ethical hacking.

This involves identifying and exploiting vulnerabilities in an organisation’s systems using the same techniques as a criminal hacker – except you don’t perform malicious actions.

Rather, an organisation hires ethical hackers to find out where its weaknesses are and how they could be exploited. Armed with this knowledge, the organisation can apply the necessary controls to mitigate the risk.

The demand for ethical hackers has skyrocketed in the past few years, as businesses realise the need for practical assessments of their systems.

If this sounds like the sort of career you’re interested in, you can develop the skills you need on our Certified Ethical Hacker (CEH) Training Course.


If you’d prefer to work in the risk management and legal aspects of cyber security, a CISMP (Certificate in Information Security Management Principles) qualification would be more suitable.

CISMP is widely regarded as the ‘qualification of choice’ for IT professionals and is recognised across the UK as an essential first rung on the ladder to a successful career.

The framework is ideal for those getting started in the industry and for professionals who require a deeper understanding of the subject to develop their overall business skills.

It’s particularly valuable to those working in the public sector, as it is part of the CESG Certified Professional (CCP) scheme, which is the government’s approved standard of competence for cyber security.


Don’t leave management qualifications until later

Most cyber security careers eventually lead towards a management position, which means that you might be leading a group of specialists in an area in which you’re not an expert.

That is normal for most industries; what’s important is that you know enough about the work they do to manage them appropriately.

As such, anyone interested in becoming a manager should consider gaining appropriate qualifications as soon as possible.

If your background is in ISO 27001, you should take the lead implementer training course, whereas if you want to develop your GDPR skills, you should take the practitioner training course or learn how to become a DPO (data protection officer).

Those with several years’ experience in cyber security may also consider becoming a CISM (Certified Information Security Manager) or CISSP (Certified Information Security Systems Professional).

Get started with our free guide

You can find out more about getting started in the industry with our Cyber Security Careers Guide.

We look a wide variety of cyber security professions and explain the skills and experience you need to get started.

You’ll also discover which training courses can help you advance in each career and how IT Governance can help.

Our training courses offer a structured learning path from Foundation to Advanced level, helping IT, privacy and security practitioners develop the skills needed to deliver best practice and compliance in organisations of all sizes.

The post What are the best cyber security training courses? appeared first on IT Governance UK Blog.