Author: hello@alienvault.com

This blog was written by an independent guest blogger.

Schools and colleges were the worst hit by cyberattacks during the global health crisis in 2020. According to a report by GCN, ransomware attacks alone affected over 1,680 schools, colleges, and universities in the US. Such attacks also targeted 44% of educational institutions across the world. Schools worldwide are back to normal sessions and for many learners, that means spending hours online studying, doing homework, and submitting assignments. 

While online learning guarantees convenience, flexibility, and affordability, it presents a major safety concern. Many teachers worry about securing schools as they transition to e-learning. Fortunately, there are plenty of useful guides for helping children stay safe online. The only downside is that these guides assume all young internet users possess the same skill levels. So, how do you teach online safety to children with learning disabilities? Keep reading to learn a few tips on how to teach students with special needs important cybersecurity skills.

Discourage sharing of important information

Online safety concerns for teachers and parents include cyberbullying, posting a lot of information, close interaction with strangers, and online scams. One of the best ways to improve student safety online is by discouraging sharing of important information via suspicious emails or links. Inform your students that any information they share online is public. 

Details students shouldn’t share on the internet include real names, phone numbers, home address, school name, and photos. Consider writing a do not share list and post it on your students’ computers. Having a visual list helps your students remember who they can talk to online and what to post. 

Teach proper use of devices and apps

Setting up limits on what content your students with special needs should access is an important step to keeping them safe from cybercriminals. To achieve the best outcome, teach students how to adjust device settings to enhance data privacy. It’s also wise to set up filters to filter search results and install virus protection software. 

Other important cybersecurity best practices for students include setting strong passwords and encrypting data on all Internet-enabled devices. Don't forget to update malware software to ensure operating systems are up to date and advise students never to open links or attachments from strangers. Also, teach the proper use of password managers to prevent data breaches. Since password managers store login information in encrypted databases, students don’t need to write passwords in books where people can access them quickly. 

Embrace gamification

Students with learning disabilities like dyslexia, ADHD, and autism have unique learning needs. For instance, when teaching neurodivergent students online and in person, you need to use different approaches. Avoid a one-size-fits-all teaching technique because some students will understand better through visuals, others study well with the help of text-speech software, interactive whiteboards, and voice dictation apps. 

You can also improve your students’ cybersecurity skills through gamification. There are many reasons special needs students love online games to learn various things, including internet safety. Gamification designed for children with learning challenges is fun and provides engaging content. Examples of cybersecurity games for kids include Interland, Privacy Pirates, Cyber Defense Quiz, and Internet Safety Hangman. 

Discuss the risk of misinformation 

While cyberbullying and interacting too much with strangers are legitimate concerns, misinformation is the most worrying online threat for students with special needs. Children with speech and language challenges, processing, and behavioral challenges may have difficulty discerning facts from fiction posted online. Based on the information consumed online, some learners will argue that some facts are fake. For instance, your student might be adamant about the fact that people landing on the moon is fake after watching a conspiracy theory video online. As a teacher or parent, you can protect students from misinformation by sharing links to reputable websites where they can fact-check information. 

Protecting children from cyberattacks while learning online is a concern for many parents and teachers. To enhance online safety for learners with learning challenges, parents and teachers should discourage sharing of sensitive information. It's also crucial to emphasize the importance of device and app settings, teach cybersecurity through gamification, and share reputable sources of information to avoid misinformation. 

The post A guide to teaching cybersecurity skills to special needs students appeared first on Cybersecurity Insiders.

This blog was written by an independent guest blogger.

Schools and colleges were the worst hit by cyberattacks during the global health crisis in 2020. According to a report by GCN, ransomware attacks alone affected over 1,680 schools, colleges, and universities in the US. Such attacks also targeted 44% of educational institutions across the world. Schools worldwide are back to normal sessions and for many learners, that means spending hours online studying, doing homework, and submitting assignments. 

While online learning guarantees convenience, flexibility, and affordability, it presents a major safety concern. Many teachers worry about securing schools as they transition to e-learning. Fortunately, there are plenty of useful guides for helping children stay safe online. The only downside is that these guides assume all young internet users possess the same skill levels. So, how do you teach online safety to children with learning disabilities? Keep reading to learn a few tips on how to teach students with special needs important cybersecurity skills.

Discourage sharing of important information

Online safety concerns for teachers and parents include cyberbullying, posting a lot of information, close interaction with strangers, and online scams. One of the best ways to improve student safety online is by discouraging sharing of important information via suspicious emails or links. Inform your students that any information they share online is public. 

Details students shouldn’t share on the internet include real names, phone numbers, home address, school name, and photos. Consider writing a do not share list and post it on your students’ computers. Having a visual list helps your students remember who they can talk to online and what to post. 

Teach proper use of devices and apps

Setting up limits on what content your students with special needs should access is an important step to keeping them safe from cybercriminals. To achieve the best outcome, teach students how to adjust device settings to enhance data privacy. It’s also wise to set up filters to filter search results and install virus protection software. 

Other important cybersecurity best practices for students include setting strong passwords and encrypting data on all Internet-enabled devices. Don't forget to update malware software to ensure operating systems are up to date and advise students never to open links or attachments from strangers. Also, teach the proper use of password managers to prevent data breaches. Since password managers store login information in encrypted databases, students don’t need to write passwords in books where people can access them quickly. 

Embrace gamification

Students with learning disabilities like dyslexia, ADHD, and autism have unique learning needs. For instance, when teaching neurodivergent students online and in person, you need to use different approaches. Avoid a one-size-fits-all teaching technique because some students will understand better through visuals, others study well with the help of text-speech software, interactive whiteboards, and voice dictation apps. 

You can also improve your students’ cybersecurity skills through gamification. There are many reasons special needs students love online games to learn various things, including internet safety. Gamification designed for children with learning challenges is fun and provides engaging content. Examples of cybersecurity games for kids include Interland, Privacy Pirates, Cyber Defense Quiz, and Internet Safety Hangman. 

Discuss the risk of misinformation 

While cyberbullying and interacting too much with strangers are legitimate concerns, misinformation is the most worrying online threat for students with special needs. Children with speech and language challenges, processing, and behavioral challenges may have difficulty discerning facts from fiction posted online. Based on the information consumed online, some learners will argue that some facts are fake. For instance, your student might be adamant about the fact that people landing on the moon is fake after watching a conspiracy theory video online. As a teacher or parent, you can protect students from misinformation by sharing links to reputable websites where they can fact-check information. 

Protecting children from cyberattacks while learning online is a concern for many parents and teachers. To enhance online safety for learners with learning challenges, parents and teachers should discourage sharing of sensitive information. It's also crucial to emphasize the importance of device and app settings, teach cybersecurity through gamification, and share reputable sources of information to avoid misinformation. 

The post A guide to teaching cybersecurity skills to special needs students appeared first on Cybersecurity Insiders.

This blog was written by an independent guest blogger.

USM Anywhere is the ideal solution for small and mid-sized businesses that need multiple high-quality security tools in a single, unified package.

There’s no reason large, global enterprises should have a monopoly on top cybersecurity technology. Solutions like USM Anywhere give smaller organizations access to security tools that are both effective and affordable.

USM Anywhere offers a centralized solution for monitoring networks and devices for security threats. It secures devices operating on-premises, remotely, and in the cloud. By combining multiple security tools into a single, streamlined interface, USM Anywhere gives smaller organizations a competitive solution for obtaining best-in-class security outcomes.

Castra's extensive experience working with USM Anywhere has given us unique insight into the value it represents. There is a clear difference in security returns and outcomes between USM Anywhere users and those that put their faith in proprietary solutions developed by managed security service providers. This is especially true for organizations with less than 1000 employees, where management is under considerable pressure to justify security expenditures.

Three ways USM Anywhere outperforms

USM Anywhere furnishes organizations with essential security capabilities right out of the box. It is a full-featured security information and event management platform that enables analysts to discover assets, assess vulnerabilities, detect threats, and respond to security incidents. It features built-in and customizable compliance reporting capabilities, as well as behavioral monitoring capabilities.

These features, along with the platform’s uniquely integrated architecture, provide valuable benefits to security-conscious organizations:

1. Automated log management

USM Anywhere enables analysts to automate log collection and event data from data sources throughout the IT environment. With the right configuration, analysts can receive normalized logs enriched with appropriate data and retain them in a compliant storage solution.

This eliminates the need for costly and time-consuming manual log aggregation, significantly improving the productivity of every employee-hour spent on security tasks. Improved logging efficiency gives security teams more time to spend on strategic, high-value initiatives that generate significant returns.

2. Cloud platform API integration

USM Anywhere integrates with the most popular cloud and productivity platforms, including Office 365 and Amazon AWS.

With the Office 365 Management API, analysts can monitor user and administrator activities throughout the entire Microsoft environment. This makes it easy for analysts to detect anomalies like users logging in from unfamiliar territories, changing mailbox privileges, or sending sensitive data outside the organization.

The CloudWatch and CloudTrail APIs allow analysts to monitor AWS environments and review log activity within the cloud. Gain real-time visibility into asset creation, security group configurations, and S3 access control changes directly through an intuitive, unified SIEM interface.

3. Orchestrated response capabilities

Analysts need accurate, real-time data on suspicious activities so they can categorize attacks and orchestrate a coherent response. USM Anywhere gives analysts access to full details about attack methods, strategies, and response guidance.

AlienApps™ users can extend USM Anywhere capabilities to third-party security and management platforms, allowing analysts to initiate and orchestrate comprehensive event response from within the USM Anywhere user interface. This allows Castra analysts to automate the integration of Palo Alto Cortex XDR capabilities and Anomali Threat Intelligence data from directly within USM Anywhere.

Make Castra your USM Anywhere partner

Castra has been an AlienVault partner since 2013, successfully deploying the company’s security technologies thousands of times. Our remarkable customer renewal rate of almost 100% stands a testament to the effectiveness of our approach. Working with Castra gives you visibility and control over your security posture, while supporting it with qualified expertise on demand.

We have worked closely with AT&T’s USM Anywhere development team for years, providing critical feedback even before AlienVault was publicly released. Our security analysts have deep knowledge of this platform and can personalize its performance to meet your security objectives and compliance needs to the letter. Speak to a Castra expert about optimizing your SIEM deployment to find out more.

The post The three core strengths of USM Anywhere appeared first on Cybersecurity Insiders.

This blog was written by an independent guest blogger.

When we think of “authentication” for our applications, most of us think of user registration, a login form, and resetting passwords. Our concerns begin and end there. But as we dive deeper and our security and compliance requirements change over time, we have to consider new password hashing algorithms, blocking bots, multi-factor authentication, and external identity providers. What started as a clear, concise set of requirements became an ever-growing list.

For new applications, we can add an identity provider like Azure Active Directory or Okta, embed any number of framework plugins, and count on those systems to handle all the complexity and change that we’d normally have to consider within our system. It’s a quick and easy exercise and centralizes all the policy across your ecosystem.

Unfortunately, most of our apps don’t fit this nice, clean, predictable world. We have years or even decades of mission critical applications sitting in our infrastructure where the source code is lost to time, the team has moved onto other projects, and the overall system is working “so please don’t touch it!” That makes a “simple checkbox task” much more complicated. We need to rethink our approach on how we access these systems.

Enter the reverse proxy 

In general client-server architectures, the client makes requests directly to the server. As the number of clients grows, it’s feasible to overwhelm the server and prevent any requests from being fulfilled. With a reverse proxy, we put a system in front of the server to act as a gateway. This gateway applies its own rules to the requests, confirms those requests meet those requirements, and forwards the acceptable requests on to the server.

To think of it another way, consider your favorite restaurant. Do you sit down with the menu, choose a dish, and shout it to the kitchen? No, that would create chaos and confusion. Instead, a waiter takes your order and divides it into pieces to tell the bartender your drink order and the kitchen your dinner selection. As each dish is ready, the kitchen assembles the pieces, and the waiter brings you the result. You don’t know or care if one or ten cooks are preparing your meal. The wait staff provides an abstraction layer between you and the kitchen without changing how the diner or the kitchen operate.

When we think back to our legacy application, the reverse proxy performs the same service. It acts as an abstraction layer for our security requirements and allows the implementation to change independently of the system we’re protecting. In fact, as our requirements change and expand, we can usually focus entirely on the reverse proxy and ignore most of the underlying legacy system. 

HTTP Basic Authentication with a reverse proxy

Now that we can gate access to our server, forcing authentication is straightforward. For the following examples, we’ll assume the application we’re protecting lives at 192.168.1.1:8080.

At the simplest level, we can start with HTTP Basic Authentication. With an Apache or NGINX-based proxy, you would use a command like this to create a new user named “katelibby”:

> htpasswd /etc/apache2/.htpasswd katelibby reverseproxyftw

and then load the resulting htpasswd file into your configuration in seconds. At ngrok, we can accomplish the same on the command line with this option:

> ngrok http 192.168.1.1:8080 — basic-auth=”katelibby:reverseproxyftw”

But be careful, unlike the htpasswd approach, the ngrok command line approach is an ephemeral user and ceases to exist when this command is interrupted. On the positive side, you don’t need any additional services and components.

Unfortunately, HTTP Basic Auth isn’t usually the best option. On the surface, it’s easy to set up and maintain but it turns into an administrative headache over time. First, an admin must create each user so they normally have the passwords and – even worse – the end user can’t reset or recover their account on their own. In general, HTTP Basic Auth is really only useful for small, simple projects with minimal or non-existent security and compliance requirements.

OAuth 2.0 and OpenID Connect with a reverse proxy 

When we go deeper into the authentication rabbit hole, we quickly get to OAuth 2.0. OAuth addresses many of the self-service aspects by completely delegating anything authentication (and authorization!)-related to an identity provider.

Luckily because OAuth is an open protocol, there are implementations for every system out there. The Apache approach to auth gives you a toolbox of options to build your own while my former colleague at Okta, Aaron Parecki covers his approach in “Use nginx to Add Authentication to Any Application.”

At ngrok, we take a different approach to support some of the major OAuth providers:

> ngrok http 192.168.1.1:8080 –oauth=google

Or if we preferred to use OpenID Connect specifically, that command would change to:

> ngrok http 192.168.1.1:8080 –oidc=https://login.identifyprovider.com –oidc-client-id=clientId –oidc-client-secret=clientSecret

Regardless of which approach we take, now our underlying system is protected with OAuth 2.0 or OpenID Connect without changing the system.

Further, since we’ve outsourced authentication to a separate identity provider, our underlying system is now under those security requirements. If our identity provider requires complex passwords, multi-factor authentication, or has IP restrictions on where to allow login, our legacy system doesn’t know and doesn’t care. We get all the benefits of those policies without having to touch the underlying system.

Is a reverse proxy the Holy Grail?

Regardless of the benefits, there are a few tradeoffs involved in choosing a reverse proxy. A reverse proxy can often view and inspect network traffic as it flows between the clients and servers. The positive take on this inspection is the proxy can detect malicious activity and block it or improve speed via compression and traffic shaping. The negative take is the proxy can log the traffic potentially providing a new target for attackers. In practice, you can mitigate the logging and introspection risks by implementing end to end encryption via TLS.

Architecturally, as the gateway to our application, it becomes a new single point of failure. Therefore, we have to plan for it to be stable, reliable, fail gracefully, and recover quickly. This may require teams to learn and implement new tooling and monitoring for observability but any reasonable reverse proxy configuration will consider those capabilities core.

Fundamentally, a reverse proxy gives you control and oversight over the legacy systems living on your network. With just a little effort, you can bring it under the umbrella of your existing security practices and policies and even expand and adapt as those requirements change. Done well, a reverse proxy will let you consider non-security aspects like traffic shaping, payload/request validation, circuit breaking, and even replacing the underlying system completely and transparently to end users.

A reverse proxy does not solve all of our problems, but a single point of access gives us power.

The post Authenticating legacy apps with a reverse proxy appeared first on Cybersecurity Insiders.

Perspective:

While there is an alphabet soup of compliance requirements and security standards frameworks, this post will focus on the two prevalent certifications frequently discussed for SaaS and B2B businesses. Security and compliance qualifications, like SOC 2 and ISO 27001, demonstrate that you apply good practices in your business. They are often classified as “security” and thought of as the technical security of your systems. However, they are broader, focusing on organizational practices supporting your security and other objectives. That includes availability (system resilience), the confidentiality of data, privacy for your users, integrity of the system processing objectives, scalable process design, and operational readiness to support significant business customers.

So, before we get into which one would you pick, how, and why, let's quickly get aligned on the key benefits of why these certifications and attestations are relevant from a business standpoint.

Background and benefits:

It helps establish brand trust and enable sales: Your customer's looking to use your software, consider your product, and your capabilities as an organization. These qualifications play an essential role in demonstrating your business is “enterprise-ready,” providing a reliable service and keeping their data secure.

It helps demonstrate compliance and establish a baseline for risk management: These certifications often become mandates from procurement teams to demonstrate supply chain security. Or they can be used to demonstrate compliance with regulations and satisfy regulatory requirements.

It helps reduce overhead and time responding to due diligence questionnaires: A significant pain point for software companies is the relentless due diligence in serving enterprise customers. Hundreds, even thousands of “security questions” and vendor audits are common. Standards like SOC 2 and ISO 27001 are designed to have a single independent audit process that satisfies broad end-user requirements.

It helps streamline and improve business operations: You adopt “good” or “best” industry practices by going through these certifications. Investors, regulators, partners, Board, the management team, and even employees benefit from implementing and validating your alignment to standards. It provides peace of mind that you are improving your security posture, helps address compliance requirements, and strengthens your essential operational practices.

Which standard is best for these goals? 

Each standard has different requirements, nuances in how they are applied, and perceptions in the market. This impacts which may be best for your business and how they help you achieve the goals above.

Below, we'll compare the two most common standards, SOC and ISO.

Often, we see that the SOC 2 reports are widely adopted and acknowledged. Many procurement and security departments may require a SOC 2 report before approving a SaaS vendor for use.  If your business handles any customer data, getting a SOC 2 report will help show your customers and users that you seriously consider data security and protection. Healthcare, retail, financial services, SaaS, cloud storage, and computing companies are just some businesses that will benefit from SOC 2 compliance certification.

What is a SOC -2 certification?

SOC-2 is based on five Trust Service Criteria (TSC) principles.

Security – making sure that sensitive information and systems are protected from security risks and that all predefined security procedures are being followed

Availability – ensuring that all systems are available and minimizing downtime to protect sensitive data

Processing integrity – verifying data integrity during processing and before authorization

Confidentiality – allowing information access only to those approved and authorized to receive

Privacy – managing personal and private information with integrity and care

SOC 2 examinations were designed by the American Institute of Certified Public Accountants (AICPA) to help organizations protect their data and the privacy of their client's information. A SOC 2 assessment focuses on an organization's security controls related to overall services, operations, and cybersecurity compliance. SOC 2 examinations can be completed for organizations of various sizes and across different sectors. 

Businesses that handle customer data proactively perform SOC 2 audits to ensure they meet all the criteria. Once an outside auditor performs a SOC 2 audit, the auditor will issue a SOC 2 certificate that shows the business complies with all the requirements if the business passes the audit. There are two types of SOC 2 audits: Type 1 and Type 2. The difference between them is simple: A Type 1 audit looks at the design of a specific security process or procedure at one point in time, while a Type 2 audit assesses how successful that security process is.

What Is ISO/IEC 27001:2013?

The ISO/IEC 27001 is an international information security standard published jointly by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC.) It is part of the ISO/IEC 27000 family of standards. It offers a framework to help organizations establish, implement, operate, monitor, review, maintain, and continually improve their information security management systems.

ISO 27001 details the specification for Information Security Management System (ISMS) to help organizations address people, processes, and technology about data security to protect the confidentiality, integrity, and availability of their information assets. The ISO 27001 framework is based on risk assessment and risk management, and compliance involves identifying information security risks and implementing appropriate security controls to mitigate them. It also includes 27017 and 27018 to demonstrate cloud security and privacy protections and /or do 27701 (privacy management system) as an extension to ISO 27001.

The intent of information protection – a common thread between both SOC and ISO 27001.

Both SOC 2 and ISO 27001 are similar in that they are designed to instill trust with clients that you are protecting their data. If you look at their principles, they each cover essential dimensions of securing information, such as confidentiality, integrity, and availability.

The good news from this comparison is that both frameworks are broadly recognized certifications that prove to clients that you take security seriously. The great news is that if you complete one certification, you are well along the path to achieving the other. These attestations and certifications are reputable and typically accepted by clients as proof that you have proper security. Suppose you sell to organizations in the United States. In that case, they will likely accept either SOC 2 or ISO 27001 as a third-party attestation to your InfoSec program. Both are equally “horizontal” in that most industries accept them.

There are several key differences between ISO 27001 vs. SOC 2, but the main difference is scope. ISO 27001 is to provide a framework for how organizations should manage their data and prove they have an entire working ISMS in place. In contrast, SOC 2 demonstrates that an organization has implemented essential data security controls. 

Which one should you go with?

Whatever certification you decide to do first, the odds are as your business grows, you will eventually have to complete both certifications to meet the requirements of your global clientele. The encouraging news is that there are more accessible, faster, and more cost-effective methods to leverage your work in one certification to reduce the amount of work you need to do in subsequent certifications. We are suggesting that you explore compliance with a proactive mindset, as it will save you time and money in the long run.

The post Security frameworks / attestations and certifications: Which one is the right fit for your organization? appeared first on Cybersecurity Insiders.

This blog was written by an independent guest blogger.

If you don’t think API security is that important, think again. Last year, 91% of organizations had an API security incident. The proliferation of SOAP and REST APIs makes it easy for organizations to tailor their application ecosystems. But, APIs also hold the keys to all of a company’s data. And as data-centric projects become more in demand, it increases the likelihood of a target API attack campaign. 

Experts agree that organizations that keep their API ecosystem open should also take steps to prevent ransomware attacks and protect data from unauthorized users. Here is a list of 12 tips to help protect your API ecosystem and avoid unnecessary security risks. 

Encryption

The best place to start when it comes to any cybersecurity protocol is encryption. Encryption converts all of your protected information into code that can only be read by users with the appropriate credentials. Without the encryption key, unauthorized users cannot access encrypted data. This ensures that sensitive information stays far from prying eyes. 

In today’s digital business environment, everything you do should be encrypted. Using a VPN and Tor together runs your network connection through a secured server. Encrypting connections at every stage can help prevent unwanted attacks. Customer-facing activities, vendor and third-party applications, and internal communications should all be protected with TLS encryption or higher. 

Authentication

Authentication means validating that a user or a machine is being truthful about their identity. Identifying each user that accesses your APIs is crucial so that only authorized users can see your company’s most sensitive information. 

There are many ways to authenticate API users:

• HTTP basic authentication
• API authentication key configuration
• IdP server tokens

OAuth & OpenID Connect

A great API has the ability to delegate authentication protocols. Delegating authorizations and authentication of APIs to an IdP can help make better use of resources and keep your API more secure. 

OAuth 2 is what prevents people from having to recall from memory thousands of passwords for numerous accounts across the internet and allows users to connect via trusted credentials through another provider (like when you use Facebook, Apple, or Google to log in or create an account online).

This concept is also applied to API security with IdP tokens. Instead of users inputting their credentials, they access the API with a token provided by a third-party server. Plus, you can leverage the OpenId Connect standard by adding an identity layer on top of OAuth. 

Audit, log, and version

Without adequate API monitoring, there is no way organizations can stop insidious attacks. Teams should continuously monitor the API and have an organized and repeatable troubleshooting process in place. It’s also important that companies audit and log data on the server and turn it into resources in case of an incident. 

A monitoring dashboard can help track API consumption and enhance monitoring practices. And don’t forget to add the version on all APIs and depreciate them when appropriate. 

Stay private

Organizations should be overly cautious when it comes to vulnerabilities and privacy since data is one of the most valuable and sought-after business commodities. Ensure error messages display as little information as possible, keep IP addresses private, and use a secure email gateway for all internal and external messaging. Consider hiring a dedicated development team that has only necessary access and use an IP whitelist and blacklist to restrict access to resources. 

Consider your infrastructure

Without a good infrastructure and security network, it’s impossible to keep your API secure. Make sure that your servers and software are up to date and ensure that regular maintenance is done to consolidate resources. You should also ensure that third-party service providers use the most up-to-date versioning and encryption protocols. 

Throttling and quotas

DDOS attacks can block legitimate users from using their dedicated resources, including APIs. Restricting access to the API and application organizations can ensure that no one will abuse your APIs. Setting throttling limits and quotas is a great way to prevent cyberattacks from numerous sources, such as a DDOS attack. Plus, you can prevent overloading your system with unnecessary requests. 

Data validation

All data must be validated according to your administrative standards to prevent malicious code from being injected into your API. Check every piece of data that comes through your servers and reject anything unexpected, significantly large, or from an unknown user. JSON and XML schema validation can help check your parameters and prevent attacks. 

OWASP Top 10

Staying up on the OWASP (Open Web Application Security Project) Top 10 can help teams implement proactive measures to protect the API from known vulnerabilities. The OWASP Top 10 lists the 10 worst vulnerabilities according to their exploitability and impact. Organizations should regularly review their systems and secure all OWASP vulnerabilities. 

API firewalling

An API firewall makes it more difficult for hackers to exploit API vulnerabilities. API firewalls should be configured into two layers. The first DMZ layer has an API firewall for basic security functions, including checking for SQL injections, message size, and other HTTP security activities. Then the message gets forwarded to the second LAN layer with more advanced security functions. 

API gateway management

Using an API gateway or API management solution can help save organizations a lot of time and effort when successfully implementing an API security plan. An API gateway helps keep data secure with tools to help monitor and control your API access. 

In addition to streamlined API security implementation, an API management solution can help you make sense of API data to power future business decisions. Plus, with the help of creative graphic design, many API management solutions and gateways offer a simple UI with easy navigation. 

Call security experts

Although cybersecurity positions are popping up worldwide, many organizations are having difficulty finding talented experts with the right security credentials to fill in the security gaps. There are ways to attract cybersecurity professionals to your company, but cybersecurity can’t wait for the right candidate. 

Call the security experts at AT&T cybersecurity to help you manage your network and API security. Plus, you can use ICAP (Internet Content Adaptation Protocol) servers to scan the payload of your APIs. 

Final thoughts

As digital tools and technologies continue to evolve, so will hackers’ attempts to exploit crucial business data. Putting some basic API security best practices in place will help prevent attacks in the future and contribute to a healthy IT policy management lifecycle. 

The best way to ensure that your APIs are safe is to create a company-wide mindset of cyber hygiene through continuous training and encouraging DevSecOps collaborative projects. However, organizations can secure their digital experiences and important data by following these simple tips to enhance their API security. 

The post API security: 12 essential best practices to keep your data & APIs safe appeared first on Cybersecurity Insiders.

Stories from the SOC is a blog series that describes recent real-world security incident investigations conducted and reported by the AT&T SOC analyst team for AT&T Managed Extended Detection and Response customers.

Executive summary

Internal Reconnaissance, step one of the Cyber Kill Chain, is the process of collecting internal information about a target network to identify vulnerabilities that can potentially be exploited.  Threat actors use the information gained from this activity to decide the most effective way to compromise the target network. Vulnerable services can be exploited by threat actors and potentially lead to a network breach. A network breach puts the company in the hands of cybercriminals. This can lead to ransomware attacks costing the company millions of dollars to remediate along with a tarnished public image. 

The Managed Extended Detection and Response (MXDR) analyst team received two alarms regarding an asset performing network scans within a customer's environment. Further investigation into these alarms revealed that the source asset was able to scan 60 unique IPs within the environment and successfully detected numerous open ports with known vulnerabilities.

Initial alarm review

Indicators of Compromise (IOC)

The initial alarm that prompted this investigation was a Darktrace Cyber Intelligence Platform event that was ingested by USM Anywhere. The priority level associated with this alarm was High, one level below the maximum priority of Critical.  Network scanning is often one of the first steps a threat actor takes when attempting to compromise a network, so it is a red flag any time an unknown device is scanning the network without permission. From here, the SOC went deeper into associated events to see what activity was taking place in the customer’s environment. The image shown below is the Darktrace alarm that initiated the investigation.

Expanded investigation

Events search

Utilizing the filters built into USM Anywhere , the events were narrowed down to the specific source asset IP address and Host Name to only query events associated to that specific asset. The following events were found that provide more information about the reconnaissance activity that was being observed.

Event deep dive

Upon reviewing the logs from the events shown above, the SOC was able to determine that the source asset scanned two separate Classless Inter-Domain Routing (CIDR) blocks, detecting, and scanning 60 unique internal devices for open ports. As shown in the log snippets below, the scans revealed multiple open ports with known vulnerabilities, most notable is Server Message Block (SMB) port 445 which is the key attack vector for the infamous WannaCry malware. Looking at the logs we can also see that the source asset detected port 5985, the port utilized by Windows Remote Management (WinRM). WinRM can be used by threat actors to move laterally in environments by executing remote commands on other assets from the compromised host. These remote commands are typically batch files performing malicious activity or implanting backdoors to maintain persistence in the network.  Lastly, we can see the asset scanning for Lightweight Directory Access Protocol (LDAP) port 389. LDAP traffic, if not encrypted properly, can be sniffed with Wireshark and potentially expose sensitive information such as usernames and passwords.

Reviewing for additional indicators

After the initial analysis of the source asset, we pivoted our event search to include assets within the target IP ranges. Using the filters in USM Anywhere, the SOC was able to search the events in the customers environment for the targeted IP addresses and analyze all events searching for any anomalous activity that would indicate a breach took place. Further review into the customer's network did not reveal any additional activity following the scanning. The SOC was unable to find any evidence that the threat actor advanced from reconnaissance to weaponization, or further up in the kill chain. This suggests that the activity is isolated for the time being.

Response

Building the investigation

Due to the nature of reconnaissance scanning, this could potentially be a threat actor attempting to discover vulnerable services on assets within the environment. The customer was advised to quarantine the asset off the network and investigate the source of the scanning activity to determine if a compromise took place. It was recommended to run a full Antivirus scan on the asset to ensure that this activity was not related to malware attempting to move laterally in their environment.

Customer interaction

The customer was notified via phone call as defined in their Incident Response Plan (IRP). The customer was able to isolate the asset off the network to prevent any additional network scans. They then began to investigate the asset by performing a software inventory of the machine to determine the source of the network scanning and reviewing the Windows Event Viewer logs to determine the user account associated with the scanning activity. The quick response of the MXDR team allowed the customer to investigate the asset before any additional actions took place as a result of the initial network scans that triggered the alarms.

The post Stories from the SOC – Detecting internal reconnaissance appeared first on Cybersecurity Insiders.

This blog was written by an independent guest blogger.

Stop, look, listen; lock, stock, and barrel; “Friends, Romans, Countrymen…” The 3 Little Pigs; Art has 3 primary colors; photography has the rule of thirds; the bands Rush and The Police; the movie The 3 Amigos. On and on it goes – “Omne trium perfectum” – “Everything that comes in threes is perfect.”

While this article doesn’t provide perfection, we’ll focus on the top three API vulnerabilities (according to OWASP). OWASP’s international standard is important to read because it’s not only developed by professionals worldwide, but it’s also read by the threat actors who will take advantage of those vulnerabilities.

OWASP determines the risk of APIs based on the level of the API vulnerability's Exploitability, Weakness Prevalence, Weakness Detectability, and Technical Impact. Therefore, the API Top 10 are in order of OWASP's own risk methodology. Their risk method doesn't consider the chance of materialization or the impact – that's left up to each business. But these three are great places to start because they've affected large companies such as Peloton in 2021.

1. API1:2019 Broken Object Level Authorization (BOLA)

In this vulnerability, aka BOLA, APIs expose endpoints that handle object identifiers, which in turn allows visitors access to numerous resources. This attack is like Insecure Direct Object Reference (IDOR), where applications use user-supplied credentials to access objects. In the API sphere, BOLA is more accurate than IDOR – the problem is broken authorization over a sequence of API calls. Every call to a data source that uses user-provided input should include object level auth checks.

Here’s a simple example of how this works.

An API call has the following path: /customers/user/bob/profile. An attacker will attempt various names in place of “bob” to see what can be accessed, such as:

/customers/user/alice/profile

/customers/user/john/profile

Even if the name is replaced with long mixed characters, if those character sequences are sequential or otherwise guessable, the problem remains and is vulnerable.

Mitigation

• Implement an authorization mechanism that relies on user policies and hierarchy.
• Use an authorization mechanism to check if the logged-in user has authorization to perform the requested action on the record in every function that uses an input from the client to access a record in the database.
• Use random and non-guessable values for record IDs.
• Evaluate the authorization checks.

2. API2:2019 Broken User Authentication

When authentication mechanisms are implemented improperly, attackers can compromise authentication tokens or exploit implementation flaws by assuming other users’ identities.

A prominent example of this vulnerability is the 2021 Parler breach. Other factors came into play in the whole breach, but at least one endpoint did not require authentication, giving anyone who found it (and someone did) unhindered access to images.

Mitigation

• Use industry-standard authentication and token generation mechanisms (and read the accompanying documentation).
• Be aware of all the possible API authentication flows in the product or service (mobile/ web/deep links that implement one-click authentication/etc.).
• Treat “forget password” endpoints as login endpoints in terms of brute force, rate limiting, and lockout protection.
• Use the OWASP Authentication Cheat Sheet.
• Implement multi-factor authentication wherever and whenever possible.
• Check for weak passwords.
• API keys should be used for client app authentication, but not user authentication.

3. API3:2019 Excessive Data Exposure

Developers, designers, and/or engineers may not take data sensitivity into consideration. They may favor using client-side filtering, which means that data is not filtered before reaching the user.

When testing, ask “What should the user know?” and display the minimum amount of data necessary.

Mitigation

• Test or capture the API calls (using, e.g., Postman or OWASP ZAP) and look for “token” or “key” to see what it reveals.
• Threat model the data to review the flow and data filtering.
• Never depend on client-side filtering of sensitive data.
• Review the API responses. Do they contain valid data?
• Determine what data type is crossing the wire. Is it sensitive, confidential, PII, etc.? If it is, then it poses both security and privacy threats.

An important aspect of security and risk management is acknowledging that nothing is 100% secure or risk-free. There's always a risk. One concept in self-defense is appearing hard to get. Someone who walks tall and confidently, has no visible jewelry or purse, and is not distracted is considered a much harder target for being accosted than someone who slumps, lazes along, has visible necklaces and bracelets, and is on the phone (distracted). The former doesn't eliminate risk but presents a greatly reduced risk.

Securing APIs needs to move toward a confident posture and reduced risk model. Attackers are looking at the OWASP API Top 10 and other lists of common attack mechanisms, then applying those to their targets. An API that has missed any of these is at much greater risk than an organization that has addressed these, even if there are some other security issues (and there are always security issues). But if attackers have a difficult time making headway on a target, then it's more likely that they'll move on. A major challenge for organizations is that one never knows when or what attackers are doing, so staying on top of security maintenance is another challenge (think of it as job security). One way to become better acquainted with API security is to examine the fundamental aspects.

Focusing efforts on a few high-risk items won’t solve all the vulnerabilities, but that focus provides immediate guidance for engineering, developers, security, and privacy teams. In turn, this provides a roadmap for projects and tasks and prevents any appearance of negligence. These active and engaged responses to known vulnerabilities increase service security and customer trust.

The post API attack types and mitigations appeared first on Cybersecurity Insiders.

This blog was written by an independent guest blogger.

It’s well known that there’s a pervasive cybersecurity skills shortage. The problem has multiple ramifications. Current cybersecurity teams often deal with consistently heavy workloads and don’t have time to deal with all issues appropriately. The skills shortage also means people who need cybersecurity talent may find it takes much longer than expected to find qualified candidates.

Most people agree there’s no single way to address the issue and no fast fix. However, some individuals wonder if global recruitment could be an option, particularly after human resources managers establish that there aren’t enough suitable candidates locally.

Current cybersecurity professionals planning career changes

A June 2022 study from Trellix revealed that 30% of current cybersecurity professionals are thinking about changing their careers. Gathering from a wider candidate pool by recruiting people on a global level could increase the number of overall options a company has when trying to fill open positions.

However, it’s essential to learn what’s causing cybersecurity professionals to want to leave the field. Otherwise, newly hired candidates may not stick around for as long as their employers hope. It’s also important to note that the Trellix poll surveyed people from numerous countries, including the United States, Canada, India, France, and Japan.

Another takeaway from the study was that 91% of people believed there should be more efforts to increase diversity in the cybersecurity sector. The study showed that most employees in the industry now are straight, white, and male. If more people from minority groups feel welcomed and accepted while working in cybersecurity roles, they’ll be more likely to enter the field and stay in it for the long term.

Appealing perks help attract workers

Some companies have already invested in global recruitment efforts to help close cybersecurity skills gaps.

For example, Microsoft recently expanded its cybersecurity skills campaign to an additional 23 countries – including Ireland, Israel, Norway, Poland, and South Africa. All the places were identified as under high threat of cybersecurity attacks. Microsoft representatives have numerous plans to get people the knowledge they need to enter the workforce confidently and fill cybersecurity roles.

The hiring initiative also includes some Asia-Pacific (APAC) countries. That’s significant since statistics suggest it will face a labor shortage of 47 million people across all job types by 2030.

Something human resources leaders must keep in mind before hiring cybersecurity professionals is that the open positions should include attractive benefits packages that are better than or on par with what other companies in the sector provide.

Since cybersecurity experts are in such high demand, they enjoy the luxury of being picky about which jobs they consider and how long they stay in them. Even though cultural differences exist, there are some similarities in what most people look for in their job prospects. Competitive salaries and generous paid time off are among the many examples.

Shortfalls persist despite 700,000 workforce entrants

Global research published in 2021 by (ISC)² found that 700,000 new people had joined the cybersecurity workforce since 2020. However, the study also showed that the worldwide pool of professionals must grow by 65% to keep pace with demand.

The study’s results also suggested that one possibility is to recruit people who don’t have cybersecurity backgrounds. The data indicated that 17% of respondents came into the field from unrelated sectors.

Some experts suggest tapping into specific population groups as a practical way to address the shortage. For example, people with autism and ADHD often have skills that make them well suited for the cybersecurity industry.

Global recruitment is not an all-encompassing solution

Hiring people from around the world could close skill gaps in situations where it’s evident there’s a lack of talent wherever a company primarily operates. However, as the details above highlight, the skills shortage is a widespread issue.

Accepting applications from a global talent pool could also increase administrative tasks when a company is ready to hire. That’s partially due to the higher number of applications to evaluate. Additionally, there are other necessities associated with aspects like visa applications or time zone specifics if an international new hire will work remotely.

People in the IT sector should ideally see global recruitment as one of many possibilities for reducing the cybersecurity skills gap severity. It’s worth consideration, but not at the expense of ignoring other strategies.

The post Can global recruitment solve the cybersecurity hiring problem? appeared first on Cybersecurity Insiders.

In the previous article, we covered the release process and how to secure the parts and components of the process. The deploy and operate processes are where developers, IT, and security meet in a coordinated handoff for sending an application into production.

The traditional handoff of an application is siloed where developers send installation instructions to IT, IT provisions the physical hardware and installs the application, and security scans the application after it is up and running. A missed instruction could cause inconsistency between environments. A system might not be scanned by security leaving the application vulnerable to attack. DevSecOps focus is to incorporate security practices by leveraging the security capabilities within infrastructure as code (IaC), blue/green deployments, and application security scanning before end-users are transitioned to the system.

Infrastructure as Code

IaC starts with a platform like Ansible, Chef, or Terraform that can connect to the cloud service provider’s (AWS, Azure, Google Cloud) Application Programming Interface (API) and programmatically tells it exactly what infrastructure to provision for the application. DevOps teams consult with developers, IT and security to build configuration files with all of the requirements that describe what the cloud service provider needs to provision for the application. Below are some of the more critical areas that DevSecOps covers using IaC.

Capacity planning – This includes rules around autoscaling laterally (automatically adding servers to handle additional demand, elastically) and scaling up (increasing the performance of the infrastructure like adding more RAM or CPU). Elasticity from autoscaling helps prevent non-malicious or malicious Denial of Service incidents.

Separation of duty – While IaC helps break down silos, developers, IT, and security still have direct responsibility for certain tasks even when they are automated. Accidentally deploying the application is avoided by making specific steps of the deploy process responsible to a specific team and cannot be bypassed.

Principal of least privilege – Applications have the minimum set of permissions required to operate and IaC ensures consistency even during the automated scaling up and down of resources to match demand. The fewer the privileges, the more protection systems have from application vulnerabilities and malicious attacks.

Network segmentation – Applications and infrastructure are organized and separated based on the business system security requirements. Segmentation protects business systems from malicious software that can hop from one system to the next, otherwise known as lateral movement in an environment.

Encryption (at rest and in transit) – Hardware, cloud service providers and operating systems have encryption capabilities built into their systems and platforms. Using the built-in capabilities or obtaining 3rd party encryption software protects the data where it is stored. Using TLS certificates for secured web communication between the client and business system protects data in transit. Encryption is a requirement for adhering with industry related compliance and standards criteria.

Secured (hardened) image templates – Security and IT develop the baseline operating system configuration and then create image templates that can be reused as part of autoscaling. As requirements change and patches are released, the baseline image is updated and redeployed.

Antivirus and vulnerability management tools – These tools are updated frequently to keep up with the dynamic security landscape. Instead of installing these tools in the baseline image, consider installing the tools through IaC.

Log collection – The baseline image should be configured to send all logs created by the system to a log collector outside of the system for distribution to the Network Operations Center (NOC) or Security Operations Center (SOC) where additional inspection and analysis for malicious activity can be performed. Consider using DNS instead of IP addresses for the log collector destination.

Blue green deployment

Blue green deployment strategies increase application availability during upgrades. If there is a problem, the system can be quickly reverted to a known secured and good working state. A blue green deployment is a system architecture that seamlessly replaces an old version of the application with a new version.

Deployment validation should happen as the application is promoted through each environment. This is because of the configuration items (variables and secrets) that are different between the environments. Typically, validation happens during non-business hours and is extremely taxing on the different groups supporting the application. With a blue green deployment, the new version of an application can be deployed and validated during business hours. Even if there are concerns when end-users are switched over during non-business hours, fewer employees are needed to participate.

Automate security tools installation and scanning

Internet facing application attacks continue to increase because of the ease of access to malicious tools, the speed at which some vulnerabilities can be exploited, and the value of the data extracted. Dynamic Scanning Tools (DAST) are a great way to identify vulnerabilities and fix them before the application is moved into production and released for end-users to access.

DAST tools provide visibility into real-world attacks because they mimic how hackers would attempt to break an application. Automating and scheduling the scanning of applications in a regular cadence helps find and resolve vulnerabilities quickly. Company policy may require vulnerability scanning for compliance with regulatory and standards like PCI, HIPPA or SOC.

DAST for web applications focuses on the OWASP top 10 vulnerabilities like SQL injection and cross-site scripting. Manual penetration (PEN) testing is still required to cover other vulnerabilities like logic errors, race conditions, customized attack payloads, and zero-day vulnerabilities. Also, not all applications are web based so it is important to select and use the right scanning tools for the job. Manual and automatic scanning can also help spot configuration issues that lead to errors in how the application behaves.

Next Steps

Traditional deployments of applications are a laborious process for the development, IT, and security teams. But that has all changed with the introduction of Infrastructure as Code, blue-green deployments, and the Continuous Delivery (CD) methodology. Tasks performed in the middle of the night can be moved to normal business hours. Projects that take weeks of time can be reduced to hours through automation. Automated security scanning can be performed regularly without user interaction. With the application deployed, the focus switches to monitoring and eventually decommissioning it as the final steps in the lifecycle.

The post DevSecOps deploy and operate processes appeared first on Cybersecurity Insiders.