Archive

Month: July 2016

Ideas to Retire is a TechTank series of blog posts that identify outdated practices in public sector IT management and suggest new ideas for improved outcomes.

Dr. John Leslie King is W.W. Bishop Professor in the School of Information at the University of Michigan and contributed a blog hammering the idea of “do more with less” calling it a “well-intentioned but ultimately ridiculous suggestion.”

King writes: “Doing more with less flies in the face of what everyone already knows: we do less with less. This is not our preference, of course. Most of us would like to do less, especially if we could have more. People are smart: they do not volunteer to do more if they will get less. Doing more with less turns incentive upside down. Eliminating truly wasteful practices and genuine productivity gains sometimes allows us to do more with less, but these cases are rare. The systemic problems with HealthCare.gov were not solved by spending less, but by spending more. Deep wisdom lies in matching inputs with outputs.”

IT managers should respond to suggestions of doing more with less by assessing what really needs to be done…what can reasonably be discarded or added that enables the IT staff to go about their responsibilities without exceeding their limits?

Considering these ideas as they relate to IT Security, a way to optimize input with outputs may be by considering a co-managed solution focused on outcome. Rather than merely acquiring technology and then watching it gather dust as you struggle to build process and train (non-existent) staff to utilize it properly, start with the end in mind – the desired outcome. If this is a well managed SIEM solution, (and associated technology) then perhaps a co-managed SIEM approach may provide the way to match output with input.

Windows gives you several ways to control which computers can be logged onto with a given account. Leveraging these features is a critical way to defend against persistent attackers. By limiting accounts to appropriate computers you can:

The first place to start using this mitigation technique is with privileged accounts. And the easiest way to restrict accounts to specified computers is with the allow and deny logon rights. In Group Policy, under User Rights, you will find an “allow” and “deny” right for each of Windows’ five types of logon sessions:

Service (when a service is started in the background, its service account is logged on in this type of session)

Batch (i.e. Scheduled Task)

Of course, if an account has both “Logon locally” and “Deny logon locally,” the deny right will take precedence. By careful architecture of OUs, group policy objects and user groups, you can assign these rights to the desired combinations of computers and users.

But because of the indirect nature of group policy and the many objects involved it, can be complicated to configure the rights correctly. It’s easy to leave gaps in your controls or inadvertently prevent appropriate logon scenarios.

In Windows Server 2012 R2, Microsoft introduced Authentication Policy Silos. Whereas logon rights are enforced at the member computer level, silos are enforced centrally by the domain controller. Basically, you create an Authentication Policy Silo container and assign the desired user accounts and computers to that silo. Now those user accounts can only be used for logging on to computers in that silo. Domain controllers only enforce silo restrictions when processing Kerberos authentication requests – not NTLM. To prevent users accounts from bypassing silo restrictions by authenticating via NTLM, silo’d accounts must also be members of the new Protected Users group. Membership in Protected Users triggers a number of different controls designed to prevent pass-the-hash and related credential attacks – including disabling NTLM for member accounts.

For what it’s worth, Active Directory has one other way to configure logon restrictions, and that’s with the Logon Workstations setting on domain user accounts. However, this setting only applies to interactive logons and offers no control over the other logon session types.

Detecting Logon Violation Attempts

You can monitor failed attempts to violate both types of logon restrictions. When you attempt to logon but fail because you have not been granted or are explicitly denied a given logon right, here’s what to expect in the security log.

Which Security Log

Event ID

Notes

Local computer being attempted for logon

4625

Logon Failure

Failure reason: The user has not been granted the requested logon type at this machine.

Status: 0xC000015B

Domain Controller

4768

Successful Kerberos TGT Request

Note that this is a successful event. To the domain controller this was as a successful authentication.

As you can see there is no centralized audit log record of logon failures due to logon right restrictions. You must collect and monitor the logs of each computer on the network.

On the other hand, here are the events logged when you attempt to violate an authentication silo boundary.

Which Security Log

Event ID

Notes

Local computer being attempted for logon

4625

Logon Failure

Failure reason: User not allowed to logon at this computer

Status: 0xC000006E

Domain Controller

4820 Failure

A Kerberos Ticket-granting-ticket (TGT) was denied because the device does not meet the access control restrictions.

The silo is identified

4768 Failed Kerberos TGT Request

Result Code: 0xC

An obvious advantage of Authentication Silos is the central control and monitoring. Just monitor your domain controllers for event ID 4820 and you’ll know about all attempts to bypass your logon controls across the entire network. Additionally, event ID 4820 reports the name of the silo which makes policy identification instant.

Restricting privileged accounts is a key control in mitigating the risk of pass-the-hash and fighting modern attackers. Whether you enforce logon restrictions with user rights on local systems or centrally with Authentication Silos make sure you don’t just use a “fire and forget” approach in which you configure but neglect monitoring these valuable controls. You need to know when an admin is attempting to circumvent controls or when an attacker is attempting to move laterally across your network using harvested credentials.

There’s a wealth of intelligence available in your DNS logs that can help you detect persistent threats.

So how can you use them to see if your network has been hacked, or check for unauthorized access to sensitive intellectual property after business hours?

All intruders in your network must re-connect with their “central command” in order to manage or update the malware they’ve installed on your system. As a result, your infected network devices will repeatedly resolve to the domain names that the attackers use. By mining your DNS logs, you can determine if known bad domain names and/or IP addresses have affected your systems. Depending on the most current “blacklist” of criminal domains is, and how rigid your network rules are regarding IP destinations that the domain names resolve to, DNS logs can help you spot these anomalies.

It’s not a a comprehensive technique for detecting persistent threats, but a good, budget friendly start.

Archives

Archives

This site uses cookies to store information on your computer. Some are essential to make our site work; others help us improve the user experience. By using the site, you consent to the placement of these cookies. Read our Privacy Statement to learn more.