The principle means giving a user account only those privileges which are essential to that user's work. For example, a backup user does not need to install software: hence, the backup user has rights only to run backup and backup-related applications. Any other privileges, such as installing new software, are blocked. The principle applies also to a user who usually does work in a normal user account, and opens a privileged, password protected account [i.e., a superuser] only when the situation absolutely demands it.
When applied to users, the terms least user access or least-privileged user account [LUA] are also used, referring to the concept that all user accounts at all times should run with as few privileges as possible, and also launch applications with as few privileges as possible. Software bugs may be exposed when applications do not work correctly without elevated privileges.
The principle of least privilege is widely recognized as an important design consideration in enhancing the protection of data and functionality from faults [fault tolerance] and malicious behavior [computer security].
From a security perspective the principle of least privilege means each part of a system has only the privileges that are needed for its function. This way even if an attacker gains access to one part, they have only limited access to the whole system.
No current OS fully abides by this approach although simpler OSs used in embedded systems have a much better chance of adhering to LP than full-fledged large system OSs like Unix derivatives.
Privilege escalation is a major component of many of the most damaging cyber attacks. Systems that have very little least privilege in their design and run several processes at highest privilege take on huge risk because if an attacker can successfully penetrate and take over such a process [or thread] it can now do anything. The attacker's malware can then read and write memory, can create or modify any existing file, and it can create and run any process. Through these and other means, an attacker can hide latent processes on the current system that may rise again later [called an advanced persistent threat [APT]] and it can spread its malice to machines to which the victim machine is connected. This was one of the strategies Stuxnet used to remain undetected.
View chapterPurchase book
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9780128024591000117
Jargon, Principles, and Concepts
Mark Osborne, in How to Cheat at Managing Information Security, 2006
Other Concepts You Need to Know
In this section, we address the concepts of least privilege, defense in depth, failure stance, and security through obscurity.
Least Privilege
The principle of least privilege dictates that you should grant only those privileges that are absolutely required. Don’t add access rights, because they might come in handy. The major advantage of this strategy is that it limits exposure to attacks, thus minimizing the possible damage inflicted by a successful infiltration.
Defense in Depth
A common problem with all security systems is that we must assume they will fail at some point in time. The principle of defense in depth counters this assumption with layers of security that ensure that one breach alone is not sufficient to allow access to critical data. A typical example of defense in depth can be found in firewall architecture when you secure an e-commerce system with, say, a PIX on the outside and Check Point Fire Wall-1 in front of the application and DB servers. The PIX may have a vulnerability, but that will not allow access to the data because the Check Point firewall will prevent it.
Failure Stance
In the event of a failure, the failure stance is the state that a device is left in:
■Fail open When failure occurs, traffic passes freely. This option is ideal for fire doors and network taps.
■Fail closed When failure occurs, traffic is blocked. This option is ideal for firewalls and access control systems.
Security through Obscurity
The “security through obscurity” strategy is based on the theory that if you keep a low profile, attackers will “pass you by.” A practical application of this policy is the nonpublication of modem numbers, divulging them only on a need-to-know basis. It must be noted that although this is a sensible precaution, it is a poor basis for long-term security and would only be effective if combined with other strategies.
View chapterPurchase book
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9781597491105500105
Smart Grid
Tony Flick, Justin Morehouse, in Securing the Smart Grid, 2011
Why Do We Need to Secure the Smart Grid?
At this point, smart grids may seem like the panacea for the world's energy problems. They promise increased efficiency, reliability, and a more economical means of distributing and transmitting power. These improvements rely on new technologies and new levels of interconnectivity built into the electrical grid, as well as cooperation among different organizations and analysis of massive amounts of data. However, with every new technology and with easier access to energy data and devices come new attack vectors that can be exploited.
Smart Grid versus Security
When most people hear the terms “new technology,” “interconnectivity,” “data sharing,” and “business partners,” the immediate thought is of new functionality and benefits. Alternatively, security professionals immediately consider the new risks that these new functionalities and benefits have introduced to the environment. Security professionals commonly rely on the principle of least privilege to secure data and resources, which restricts access. As a result, security departments sometimes conflict with business units and security controls can sometimes conflict with new functionality; however, properly implemented security controls should not impede proper functionality. The purpose of a security control is to enable the functionality to operate correctly and protect against abuse and misuse. Ideally, security professionals would work with business units to ensure the new functionality operates in a secure manner, while striving to maintain the original intended purpose.
Note
The principle of least privilege requires that a user be given no more privileges than necessary to perform his/her job function.9 By limiting access to only the required users, the risk introduced is reduced to an acceptable and manageable level.
Completely secure applications, networks, or environments do not exist and smart grids will not be an exception. Marketing schemes that advertise “Hacker Proof” systems are simply marketing schemes and have never held up in the real world. Although each of the identified smart grid components introduces much needed functional or operational improvements, they also introduce new vulnerabilities and additional risk into the electrical grid. If not properly managed, attackers will exploit these vulnerabilities for various, common motives including curiosity, profit, notoriety, activism, and warfare.
Mapping Smart Grid Goals to Security
One of the often-mentioned goals of smart grids is to increase the security of the electric grid. This may make security seem like an additional feature; however, security will need to be integrated into smart grids to be effective. Confidentiality, integrity, and availability [CIA] are the core principles of information security that must be applied to ensure the smart grid goals are achieved.
As explained in the “Justifications for Smart Grids” section of this chapter, one of the intended improvements of smart grids over the traditional grid is reliability. Reliability can be mapped to the information security principles of availability and integrity. Security is responsible for preventing all forms of denial of service [DoS], which includes both human initiated and environmental attacks. With the proper security controls, smart grids are able to either prevent or minimize the negative impact of DoS; thus, increasing the reliability of the grid.
Data analysis will play a major role in smart grids and the accuracy, or integrity, of the data is vital. Appropriate security controls are required to ensure collected data has not been tampered with. For example, smart meters will be sending consumption statistics to the utility company for billing and operational purposes. A security mechanism, such as hashing, could be used in this example to enable the utility company to validate the consumption data and ensure their customers are accurately billed.
For smart grids to be successful, their benefits can not significantly increase costs for utility companies, and ultimately consumers. The implementation and operational costs of smart grids must not affect the affordability. Although the exact amount is unknown, recent estimates put the cost of electricity theft at $6 billion per year.10 Meter tampering is one of the largest methods for electricity theft in the current grid, and similarly, smart meters used in smart grids are expected to be targeted. Appropriate security controls will be required to ensure the integrity of smart meters, as well as each component in the smart grid. Although eliminating fraud and electricity theft is unrealistic, reducing the amount will result in significant savings for the utility companies. As a result, allowing utility companies to charge customers cheaper rates.
Renewable energy sources are intended to play a major role in the future electric grid. Electricity theft is a concern that utility companies have faced for decades; however, a new related concern will be with consumers, fraudulently, selling electricity to the grid. If a customer installs solar panels on their roof, they will have the ability to sell excess electricity to the grid; however, utility companies will need to ensure that they are not paying for spoofed electricity. Similar to the affordability goal, the integrity of smart grid components will be vital to accommodating renewable energy sources in an effective manner.
One proposed method to reduce our carbon footprint is to reduce our energy consumption. Utilizing the data collected through components of the smart grid, utility companies and third parties will provide consumers with real-time usage statistics to help consumers modify their habits to reduce their energy usage. Due to privacy concerns, the confidentiality of this information must be maintained through proper security controls, such as encryption.
View chapterPurchase book
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9781597495707000017
Filtering User Input
In Hacking the Code, 2004
Limiting Attack Scope
Summary:Use security permissions to limit the scope of attacks.Threats:Malicious input
It might be impossible to build a bullet-proof application that is impervious to all current and future application-level attacks. You can filter input and reduce your attack surface, but you must also consider that someone might eventually find a way to exploit your code. Build your application so that exploiting your code does not provide much information for the attacker.
Least Privilege
An important strategy is to always follow the principle of least privilege. Consider the security context of the Web application user and evaluate this user's access to the following:
▪The file system
Registry keys
▪Executables
▪COM components
▪WMI classes
▪TCP/IP ports
▪Databases
▪Other Web sites on the same server
Plan the security context of your Web application to properly limit access to these items. Careful attention to user security will contain and separate the Web application from the rest of the operating system.
Server-Side Code
A common mistake Web developers make is assuming that server-side code is protected from intruders. Although it is meant to be protected, experience has shown us that this is not always the case. You should work with the assumption that this code is not safe, and therefore take appropriate precautions with what you include in these files. Server-side code is not an appropriate place to store secrets such as passwords, database connection strings, or other sensitive information. Sometimes something as simple as a comment could reveal vital information for an intruder to further an attack. Look at your server-side code from the perspective of a hacker to see what information might be a security risk.
Security Policy
▪
Use the principle of least privilege to limit the access of Web users.
▪Avoid storing passwords, private comments, or other sensitive information in server-side code.
View chapterPurchase book
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9781932266658500382
Operating System Security
Jason Andress, in The Basics of Information Security [Second Edition], 2014
Apply the principle of least privilege
As we discussed in Chapter 3, the principle of least privilege dictates that we only allow a party the absolute minimum permission needed for it to carry out its function. Depending on the operating system in question, we may find this idea put into practice to a greater or a lesser extent. In almost any modern operating system, we can find the tasks a particular user is allowed to carry out separated into those that require administrative privileges and those that do not.
In general, normal operating system users are allowed to read and write files, and perhaps execute scripts or programs, but they are limited to doing so within a certain restricted portion of the file system. Normal users are generally not allowed to carry out tasks such as modifying the way hardware functions, making changes to the files on which the operating system itself depends, and installing software that can change or affect the entire operating system. Such activities are generally restricted to those users that are allowed administrative access.
On most UNIX and Linux-like operating systems, we can often see such roles strictly enforced. Although it would be possible for the administrator of such a system to allow all users to act with the privileges of an administrator, this is generally not the convention and administrative or “root” access is often guarded carefully. On Microsoft operating systems, we can often find the exact opposite to be true. On a windows system the default is to give users more control, so care needs to be taken to change permissions to be more restrictive. While there are more threats focused on MS due to the fact they have larger market share, the security posture for any system is based on the administrator. The same paradigm exists between Apple IOS and Android IOS in the smartphone market.
When we allow the average system user to regularly function with administrative privileges, we leave ourselves open to a wide array of security issues. If the user executes a malware-infected file or application, he does so as the administrator and that program has considerably more freedom to alter the operating system and other software installed on the host. If an attacker compromises a user’s account, and that account has been given administrative rights, we have now given the keys to the entire system directly to the attacker. Nearly any type of attack we might discuss, launched from nearly any source, will have considerably more impact when allowed access to administrative rights on a host. Thus one of the first actions a hacker will take if they break in via a user account is privilege escalation. It is important to monitor admin accounts for misuse!
If, instead, we limit the privileges on our systems to the minimum needed in order to allow our users to perform their required tasks, we go a long way toward mitigating many security issues. In many cases, attacks will fail entirely when an attacker attempts to run them from a user account running with a limited set of permissions. This is a very cheap security measure we can put in place and is simple to implement. Many users will complain about the inability to install new software, so it is key to have policy supporting this practice and ensure users understand the reason for the policy.
View chapterPurchase book
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9780128007440000117
Introducing Nmap
Angela Orebaugh, Becky Pinkard, in Nmap in the Enterprise, 2008
Executable and End-User Requirements
As with almost any security-related application, the first things to think about when starting the installation process includes security of the user context for the application and what permissions are required to manipulate the executable. Commonly you will find that the user must have root permissions on a UNIX system and administrator rights on a Windows box for both application installation and execution. Security best practices for accountability dictate that in order for administrative access to be properly tracked, Nmap users must have credentials that are individually identifiable. For example, John must have a personal use account and an administrative use account, both of which personally identify John as the account holder. If a common administrative username is utilized across the team, you have lost all tracking and auditing abilities. Shared “administrator” or “root” usage can be a hard habit to break; however it only takes getting caught by one auditing requirement to justify making the break.
This is connected to another important security best practice, the principle of least privilege. If John’s day-to-day work does not require administrative access, he should be logged in with his personal use account the majority of time. He must only switch to the administrative account when and if the details of his work require those extra access privileges. The theory behind this practice is that by limiting his access to the administrative account, he is helping to limit exposure to any vulnerability that might be associated with the use of that account. For example, many worms have achieved superior results for the simple reason that users were logged on at the time of infection with higher-than-necessary privilege. There are also ways of limiting users’ access by properly setting up and utilizing user groups or granting temporary access via commands like run as in the Windows Active Directory environment. Access control can also be implemented in the UNIX world via the use of group permissions and commands like sudo.
Note
Sudo is a command that gives system administrators the ability to grant individual users or groups of users special access to run commands with root access or as another user. Sudo also tracks the user’s input during their sudo session. A sudoers file must be configured on the system where the user requires access. You can learn more about this command by reading the UNIX man page associated with it.
View chapterPurchase book
Read full chapter
URL: //www.sciencedirect.com/science/article/pii/B9781597492416000029
ISA 2004 Client Types and Automating Client Provisioning
Dr.Thomas W. Shinder, Debra Littlejohn Shinder, in Dr. Tom Shinder's Configuring ISA Server 2004, 2005
Allows Strong User/Group-Based Authentication for All Winsock Applications Using TCP and UDP Protocols
The Firewall client software transparently sends user information to the ISA 2004 firewall. This allows you to create Access Rules that apply to users and groups and allow or deny access to any protocol, site, or content, based on a user account or group membership. This strong user/group-based outbound access control is extremely important. Not all users require the same level of access, and users should only be allowed access to protocols, sites, and content they require to do their jobs.
NOTE
The concept of allowing users access to only the protocols, sites, and content they require is based on the principle of least privilege. The principle of least privilege applies to both inbound and outbound access. For inbound access scenarios, Server and Web Publishing rules allow traffic from external hosts to Internal network resources in a highly controlled and monitored fashion. The same should be true for outbound access. In traditional network environments, inbound access is highly limited while users are allowed outbound access to virtually any resource they desire. This weak approach to outbound access control can put not only the corporate network at risk, but other networks as well, as Internet worms can easily traverse firewalls that do not restrict outbound access.
The Firewall client automatically sends user credentials [user name and password] to the ISA 2004 firewall. The user must be logged on with a user account that is either in the Windows Active Directory or NT domain, or the user account must be mirrored on the ISA 2004 firewall. For example, if you have an Active Directory domain, users should log on to the domain, and the ISA 2004 firewall must be a member of the domain. The ISA 2004 firewall is able to authenticate the user and allows or denies access based on the user's domain credentials.
If you do not have a Windows domain, you can still use the Firewall client software to control outbound access based on user/group. In this case, you must mirror the accounts that users log on to on their workstations to user accounts stored in the local Security Account Manager [SAM] on the ISA 2004 firewall computer.
For example, a small business does not use the Active Directory, but they do want strong outbound access control based on user/group membership. Users log on to their machine with local user accounts. You can enter the same user names and passwords on the ISA 2004 firewall, and the ISA 2004 firewall will be able to authenticate the users based on the same account information used when logging on to their local machines.