• Central provisioning of user accounts by the IT helpdesk
• Ability to reliably disable terminated employees from a single place

When the business set up a new application or server, they would request a new AD group be created, with the group membership delegated to a business level administrator.  The new server or application would be configured to rely on AD for authentication and the new AD group(s) to grant permissions.  This worked well for many years.

Until we were bought.  We were bought by a much larger company with much more mature process and security requirements.  In particular, each “permission” needed to have an identified owner, and a period revalidation that all employees with that permission still require it.  The requirement was very sensible and did not seem, on the surface, to be problematic.  After all, we had consolidated all access permissions into AD.  Complying with the new requirement seemed like it would be easy until we started to map it out.

We quickly realized that we had a mess on our hands.  Over the course of a decade, several thousand permission groups had been added by the business areas.  Each time an application was updated that required separating user permissions out a bit differently, a new set of groups was requested (or a mix of re purposing existing groups and requesting new groups).  Existing groups not reused were simply abandoned.

There was no documentation of the permission set that a given group provided.  The business units had simply taken the AD permissions and leveraged them as needed. For example, one business unit had an application they built which used AD groups to assign permissions within the application.  A specific section of the application was built for server administrators in that business unit.  The team subsequently rebuilt a number of Windows and Linux servers, using the same AD group used by the application to provide administrator access to those servers.

The plan to consolidate authentication and authorization into Active Directory was a noble one, however, the lack of a solid process to map AD groups to permissions and the dependencies of systems and servers to AD created a serious problem.  This gap created a circumstance where employees may have had the opportunity to access systems or applications with permissions that they should not have had.

Don’t become complacent with technology like we did.  Ensure that robust logical access policies and processes exist, as they are safety net to avoid serious problems.  A good consideration of risks and use cases would have easily identified the gap.  But, so would a consideration of how to re-validate employee access to permissions in order to comply with a company policy.

The Dangers of Distributed Group Management is a post from: Risking IT - Risk Management & Information Security

Some would say this is security through obscurity, and to an extent, it is.  It’s hard to find a real-world parallel to this, but I’ll try:

Imagine your house has a certain brand of locks on all the doors.  Someone finds a weakness in the lock that lets someone open the locked door extremely easily.  That’s the vulnerable web site.  Now, imagine the lock manufacturer keeps a list of all the houses in the world that use the problematic lock, and on which doors the lock is installed.  Now think about leaving copies of that list all over the place.  That seems pretty crazy, but in Internet terms, trying to keep that list private would be called “security through obscurity”.  Indeed, the Internet example is much more aggressive, since location is irrelevant and the break-in’s can be scripted to happen at a rate of hundreds or thousands per minute.

I am not proposing that the copyrights & version numbers be removed as standard practice as an alternative to other security measures – to do so would be very foolish.  This simply reduces or eliminates the automation and mass exploit capabilities that attackers currently have.

So, what got me thinking about that was this log I saw today for another site I administer, syslog.org:

71.52.247.235 – - [26/Mar/2010:10:07:54 -0400] “GET /forum/web-server-logs/continuing-attack-attempts-against-smf/ HTTP/1.1″ 200 32542 “http://www.google.com/search?q=%22SMF+%C2%A9+2006-2009%2C+Simple+Machines+LLC%22&ie=utf-8&oe=utf-8&aq=t&client=firefox-a&rlz=1R1GGGL_en___US363″ “Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2 GTB6 (.NET CLR 3.5.30729)”

If you paste the referrer into your web browser, you can see that the visitor came from a Google search for the term: “SMF © 2006-2009, Simple Machines LLC”.  In this case, the “visitor” was not out to attack the site.  He was simply a forum spammer who creates an account and decorates that account with links to sites he is promoting.  It’s pretty clever, actually, since good forum mods will react to spammy forum posts, resulting in the post and the account being deleted.  But, simply creating the account generally doesn’t set off an alarm, so the account quietly sits there with it’s payload of links waiting to be indexed by search engines.

This is yet another reason to stop the madness of including the standard copyright for such software on a web site.  In this case, the spammer specifically targeted Simple Machines forums.  He most likely started at the top of the list registering accounts, working his way down, and may even have a script engine that does most of the work for him.  This is mostly a nuisance, but it does indicate that there are not many upsides, and a lot of downsides to letting search engines create nice, neat lists of which sites are running which software.

Some software is militant about the copyright being displayed, others are more relaxed.  Generally, even the most strict projects will allow removing the version number.  It is prudent to remove as much information as the license will permit, to make your site less of a target.

Displaying Copyright & Version Information on Web Sites is a post from: Risking IT - Risk Management & Information Security

At it’s core, risk management is the assessment of business risks and the deliberate mitigation or acceptance of identified risks.  The process of identifying and rating risks is called a Risk Assessment. Standard frameworks have been developed from various disciplines, such as Business Continuity and Information Security, to aid in identifying and ranking risks.  Viewed through the lens of a risk assessment, the necessary depth of mitigation can be defined and justified.

With this site, I intend to convey what I have learned about risk management during my career, and continue to learn.  Expect the content to be slanted toward the security side of the scale, with some disaster recovery & business continuity thrown in.

What Is Risk Management? is a post from: Risking IT - Risk Management & Information Security