What will it take for policy makers to take cybersecurity seriously? Not minimal-change seriously. Not here-and-there seriously. But really seriously. What will it take for policy makers to take cybersecurity seriously enough to enact substantive legislative changes that would address the problems? It’s not enough for the average person to be afraid of cyberattacks. They need to know that there are engineering fixes—and that’s something we can provide.

For decades, I have been waiting for the “big enough” incident that would finally do it. In 2015, Chinese military hackers hacked the Office of Personal Management and made off with the highly personal information of about 22 million Americans who had security clearances. In 2016, the Mirai botnet leveraged millions of Internet-of-Things devices with default admin passwords to launch a denial-of-service attack that disabled major Internet platforms and services in both North America and Europe. In 2017, hackers—years later we learned that it was the Chinese military—hacked the credit bureau Equifax and stole the personal information of 147 million Americans. In recent years, ransomware attacks have knocked hospitals offline, and many articles have been written about Russia inside the U.S. power grid. And last year, the Russian SVR hacked thousands of sensitive networks inside civilian critical infrastructure worldwide in what we’re now calling Sunburst (and used to call SolarWinds).

Those are all major incidents to security people, but think about them from the perspective of the average person. Even the most spectacular failures don’t affect 99.9% of the country. Why should anyone care if the Chinese have his or her credit records? Or if the Russians are stealing data from some government network? Few of us have been directly affected by ransomware, and a temporary Internet outage is just temporary.

Cybersecurity has never been a campaign issue. It isn’t a topic that shows up in political debates. (There was one question in a 2016 Clinton–Trump debate, but the response was predictably unsubstantive.) This just isn’t an issue that most people prioritize, or even have an opinion on.

So, what will it take? Many of my colleagues believe that it will have to be something with extreme emotional intensity—sensational, vivid, salient—that results in large-scale loss of life or property damage. A successful attack that actually poisons a water supply, as someone tried to do in January by raising the levels of lye at a Florida water-treatment plant. (That one was caught early.) Or an attack that disables Internet-connected cars at speed, something that was demonstrated by researchers in 2014. Or an attack on the power grid, similar to what Russia did to the Ukraine in 2015 and 2016. Will it take gas tanks exploding and planes falling out of the sky for the average person to read about the casualties and think “that could have been me”?

Here’s the real problem. For the average nonexpert—and in this category I include every lawmaker—to push for change, they not only need to believe that the present situation is intolerable, they also need to believe that an alternative is possible. Real legislative change requires a belief that the never-ending stream of hacks and attacks is not inevitable, that we can do better. And that will require creating working examples of secure, dependable, resilient systems.

Providing alternatives is how engineers help facilitate social change. We could never have eliminated sales of tungsten-filament household light bulbs if fluorescent and LED replacements hadn’t become available. Reducing the use of fossil fuel for electricity generation requires working wind turbines and cost-effective solar cells.

We need to demonstrate that it’s possible to build systems that can defend themselves against hackers, criminals, and national intelligence agencies; secure Internet-of-Things systems; and systems that can reestablish security after a breach. We need to prove that hacks aren’t inevitable, and that our vulnerability is a choice. Only then can someone decide to choose differently. When people die in a cyberattack and everyone asks “What can be done?” we need to have something to tell them.

We don’t yet have the technology to build a truly safe, secure, and resilient Internet and the computers that connect to it. Yes, we have lots of security technologies. We have older secure systems—anyone still remember Apollo’s DomainOS and MULTICS?—that lost out in a market that didn’t reward security. We have newer research ideas and products that aren’t successful because the market still doesn’t reward security. We have even newer research ideas that won’t be deployed, again, because the market still prefers convenience over security.

What I am proposing is something more holistic, an engineering research task on a par with the Internet itself. The Internet was designed and built to answer this question: Can we build a reliable network out of unreliable parts in an unreliable world? It turned out the answer was yes, and the Internet was the result. I am asking a similar research question: Can we build a secure network out of insecure parts in an insecure world? The answer isn’t obviously yes, but it isn’t obviously no, either.

While any successful demonstration will include many of the security technologies we know and wish would see wider use, it’s much more than that. Creating a secure Internet ecosystem goes beyond old-school engineering to encompass the social sciences. It will include significant economic, institutional, and psychological considerations that just weren’t present in the first few decades of Internet research.

Cybersecurity isn’t going to get better until the economic incentives change, and that’s not going to change until the political incentives change. The political incentives won’t change until there is political liability that comes from voter demands. Those demands aren’t going to be solely the results of insecurity. They will also be the result of believing that there’s a better alternative. It is our task to research, design, build, test, and field that better alternative—even though the market couldn’t care less right now.

This essay originally appeared in the May/June 2021 issue of IEEE Security & Privacy. I forgot to publish it here.

Read More

Security operations provider Expel has announced the general availability of Expel managed detection and response (MDR) for Kubernetes. The firm said the product enables customers to secure their business across their Kubernetes environment and adopt new technologies at scale without being hindered by security concerns. It has also been designed to align with the MITRE ATT&CK framework to help teams remediate threats and improve resilience, Expel added.

Kubernetes is an open-source orchestration system that relies on containers to automate the deployment, scaling, and management of applications, usually in a cloud environment. Over time, it has become the de facto operating system of the cloud, but can also pose significant security risks and challenges for businesses.

To read this article in full, please click here

Read More

The content of this post is solely the responsibility of the author.  AT&T does not adopt or endorse any of the views, positions, or information provided by the author in this article. 

A radius server uses a network protocol for remote user authentication and authorization. It is a client/server protocol that allows a remote user to access a network using a shared secret (usually a password). RADIUS servers are typically located on the perimeter of a network and use port 1812 (UDP) or 1645/1813 (TCP).

RADIUS was originally developed by Livingston Enterprises, Inc. in 1991. It is now an IETF standard (RFC 2865). The following are the most important things to know about RADIUS server authentication.

 RADIUS is a remote authentication dial-in user service

It was developed to provide centralized authentication, authorization, and accounting management for networked devices such as routers and switches.

What does dial-in refer to here? Dial-in is a type of authentication that allows a user to connect to a network remotely using a phone line or other connection. RADIUS servers are used to manage user access to a network. They can be used to control who can access the network, what services they can use, and how much bandwidth they can consume.

 RADIUS is an alternative to TACACS and is often used in conjunction with TACACS+ for authentication and authorization

The reason for this is that RADIUS is typically used for remote access, while TACACS+ is usually used for device administration. While both protocols can be used for both purposes, RADIUS is usually the preferred protocol for remote access.

 A RADIUS server typically uses UDP port 1812 (or TCP port 1645/1813) to communicate with clients

RADIUS servers typically listen on UDP port 1812 (or TCP port 1645/1813). When a RADIUS client sends a request to the server, it includes the secret key in the request. The server uses this key to authenticate the client and authorize the request.

RADIUS is a client/server protocol, which means that each RADIUS client must have a corresponding RADIUS server. A RADIUS client is typically a network device such as a router or switch. A RADIUS server is a computer that runs the RADIUS software and manages user access to the network.

What this means is that for a user to be able to access the network, they must first authenticate with the RADIUS server. The RADIUS server then authorizes the user’s access to the network and controls what services they can use.

 RADIUS uses a client/server architecture

The RADIUS server is responsible for authenticating users and maintaining their account information, while the RADIUS client is typically a network device that forwards authentication requests to the server. The reason this distinction matters is that it allows the server to be centrally located and managed, while the clients can be distributed throughout the network. This architecture also makes it possible for the server to authenticate users against multiple databases, such as an LDAP server or a local file.

The implications of this are that if the server goes down, the entire network will be unavailable to users. This is why it is important to have redundant RADIUS servers in a production environment.

 A RADIUS server can authenticate users against multiple databases

RADIUS supports multiple authentication methods, including PAP, CHAP, MS-CHAP, and EAP. PAP is the simplest authentication method and sends the username and password in clear text. CHAP encrypts the password but sends it over the network in plain text. MS-CHAP encrypts both the username and password. EAP is a more secure authentication method that uses digital certificates.

 RADIUS uses UDP for transport

RADIUS uses UDP as its transport protocol. UDP is a connectionless protocol, which means that each packet is sent independently and does not require a connection to be established beforehand. This makes RADIUS very scalable, as it can support a large number of clients without requiring a lot of resources on the server.

It matters that RADIUS uses UDP for transport because UDP is a less reliable protocol than TCP. This means that RADIUS packets can be dropped or lost in transit. However, this is usually not a problem because RADIUS uses retransmission and error checking to ensure that packets are delivered reliably.

 The RADIUS server must have a shared secret with the clients

The RADIUS server and clients must have a shared secret, which is used to encrypt and decrypt packets. This shared secret is typically a password or phrase that is known only to the server and clients. Without the shared secret, an attacker would not be able to read or modify the packets being exchanged between the server and clients.

 RADIUS uses Access-Request and Access-Accept packets

When a client sends an authentication request to a RADIUS server, it does so using an Access-Request packet. The server then responds with an Access-Accept or Access-Reject packet, depending on whether the authentication was successful. If the authentication was successful, the server will also include an Access-Challenge packet, which contains a challenge that the client must answer to prove its identity.

 RADIUS can be used for AAA

RADIUS can be used for AAA, which stands for Authentication, Authorization, and Accounting. Authentication is the process of verifying a user’s identity, authorization is the process of determining what resources a user is allowed to access, and accounting is the process of tracking and billing for a user’s usage.

AAA is a common security model that is used to control access to network resources.

 RADIUS is standardized by the IETF

RADIUS is a standards-based protocol, which means that it is defined by an Internet Engineering Task Force (IETF) specification. The most recent version of the RADIUS specification is RFC 2865, which was published in June 2000.

 RADIUS is commonly used by ISPs

RADIUS is commonly used by Internet service providers (ISPs) to authenticate and authorize users who are trying to access the internet. RADIUS is also used by corporate networks to authenticate and authorize users who are trying to access the network.

 There are a few different RADIUS implementations

There are a few different RADIUS implementations, including FreeRADIUS, Microsoft NPS, and Cisco ACS. FreeRADIUS is the most popular open-source RADIUS server. Microsoft NPS is the RADIUS server included in Windows Server. Cisco ACS is a commercial RADIUS server from Cisco Systems.

Conclusion

These are the most important things to know about RADIUS server authentication. RADIUS is a critical part of many network security systems, and understanding how it works is essential for anyone who is responsible for managing a network.

Read More

A ransomware attack has again put the personal information of innocent parties at risk after it was revealed that a data breach has potentially exposed the medical records of more than three million people.

Read more in my article on the Hot for Security blog.

Read More

Group laundered funds via 100 bank accounts

Read More

A core pillar of a mature cyber risk program is the ability to measure, analyze, and report cybersecurity threats and performance. That said, measuring cybersecurity is not easy. On one hand business leaders struggle to understand information risk (because they usually are from a non-cyber background), while on the other, security practitioners get caught up in too much technical detail which ends up confusing, misinforming, or misleading stakeholders.

In an ideal scenario, security practitioners must measure and report cybersecurity in a way that senior executives understand, find useful, satisfy curiosity, and lead to actionable outcomes.

What can be measured in cybersecurity?

To read this article in full, please click here

Read More

Attack reached 71 million requests-per-second

Read More

Sanctioned mixer Blender is actually Sinbad, says Elliptic

Read More