Archive

Old dogs, new tricks

Doris Lessing passed away at the end of last year. She was the freewheeling Nobel Prize-winning writer on racism, colonialism, feminism and communism who died November 17 at the age of 94, was prolific for most of her life. But five years ago, she said the writing had dried up. “Don’t imagine you’ll have it forever,” she said, according to one obituary. “Use it while you’ve got it because it’ll go; it’s sliding away like water down a plug hole.”

In the very fast changing world of IT, it is common to feel like an old fogey. Everything changes at bewildering speed. From hardware specs to programming languages to user interfaces. We hear of wunderkinds whose innovations transform our very culture. Think Mozart, Zuckerberg to name two.

Tara Bahrampour examined the idea, and quotes author Mark Walton, “What’s really interesting from the neuroscience point of view is that we are hard-wired for creativity for as long as we stay at it, as long as nothing bad happens to our brain.”

The field also matters.

Howard Gardner, professor of cognition and education at the Harvard Graduate School of Education says, “Large creative breakthroughs are more likely to occur with younger scientists and mathematicians, and with lyric poets, than with individuals who create longer forms.”

In fields like law, psychoanalysis and perhaps history and philosophy, on the other hand, “you need a much longer lead time, and so your best work is likely to occur in the latter years. You should start when you are young, but there is no reason whatsoever to assume that you will stop being creative just because you have grey hair.” Gardner said.

Old dogs take heart; you can learn new tricks as long as you stay open to new ideas.

Fail How To: Top 3 SIEM implementation mistakes

Over the years, we had a chance to witness a large number of SIEM implementations, with results from the superb to the colossal failures. What is common with the failures? This blog by Keith Strier nails it:

1) Design Democracy: Find all internal stakeholders and grant all of them veto power. The result is inevitably a mediocre mess. The collective wisdom of the masses is not the best thing here. A super empowered individual is usually found at the center of the successful implementation. If multiple stakeholders are involved, this person builds consensus but nobody else has veto power.
2) Ignore the little things: A great implementation is a set of micro-experiences that add up to make the whole. Think of the Apple iPhone, every detail from the shape, size, appearance to every icon and gesture and feature converges to enhance the user experience. The path to failure is just focus on the big picture, ignore the little things from authentication to navigation and just launch to meet deadline.

3) Avoid Passion: View the implementation as non-strategic overhead; implement and deploy without passion. Result? At best, requirements are fulfilled but users are unlikely to be empowered. Milestones may be met but business sponsors still complain. Prioritizing deadlines, linking IT staff bonuses to delivery metrics, squashing creativity is a sure way to launch technology failures that crush morale.”

Monitoring File Permission Changes with the Windows Security Log

Unstructured data access governance is a big compliance concern.  Unstructured data is difficult to secure because there’s so much of it, it’s growing so fast and it is user created so it doesn’t automatically get categorized and controlled like structured data in databases.  Moreover unstructured data is usually a treasure trove of sensitive and confidential information in a format that bad guys can consume and understand without reverse engineering the relationship of tables in a relational database.

Most of this unstructured data is still found on file shares throughout the network, and file system permissions are the main control over this information.  Therefore knowing when permissions change unstructured is critical to governance and control. File permissions should normally be fairly static but end-users are (by default) the owner of files and subfolders they create and can therefore change permissions on those files. And of course, administrators can change permissions on any object.  Either way you need to know when this happens. Here’s how to do it with the Windows Security Log.

First we need to enable the File System audit subcategory.  You’ll find this in any group policy object under Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\System Audit Policies\Object Access.  Enable File System for success.  (By the way, make sure you also enable Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Audit: Force audit policy subcategory settings to override audit policy category settings to make sure your audit policy takes effect.) Now you need to enable object level auditing on the root folders containing your unstructured data.  For example, if you have a shared folder called c:\files, go to that folder in Windows Explorer, open the security tab of the folders properties, click Advanced and select the Auditing tab.  Now add an entry for Everyone that enables successful use of the Change permissions as shown below.

File permission change

At this point Windows will begin generating two events each time you change permissions on this folder or any of its subfolders or files.  One event is the standard event ID 4663, “An attempt was made to access an object”, which is logged for any kind of audited file access like read, write, delete, etc.  That event will show WRITE_DAC under the Access Request Information but it doesn’t tell you what the actual permission change was.  So instead, use event ID 4670, “Permissions on an object were changed”, which provides the before and after permissions of the object under Permissions Change as shown in the example below.

File permission change

“What does D:AI(A;ID;FA;;;AU)(A;ID;FA;;;WD)(A;ID;FA;;;BA)(A;ID;FA;;;SY)(A;ID;0x1200a9;;;BU) mean?” This is the original access control list of asdf.txt but in the very cryptic Security Descriptor Definition Language (SDDL).  SDDL definitely isn’t something you want to manually parse and translate on a regular basis, but you can when necessary.

Look for the “D:” which is close to the beginning of the string or even the very beginning in this case.  “D:” means Discretionary Access Control List (DACL) which are the actual permissions on the object as opposed to other things that show up in a security descriptor – like owner, primary group and the audit policy (aka SACL).  Until you hit another letter-colon combination like “S:” you are looking at the object’s permissions.  An ACL is made up of Access Control Entries which correspond to each item in the list you see in the Permissions tab of an object’s properties dialog.  But in SDDL before listing the ACEs comprising the ACL you will see any flags that affect the entire ACL as a whole.  In the example above you see AI as the first element after D:.  AI stands for SDDL_AUTO_INHERITED which means permissions on parent objects are allowed to propagate down to this object.

Now come the ACEs.  In SDDL, each ACE is surrounded by parenthesis and the fields within it delimited by semicolons.  The first ACE in the event above is (A;ID;FA;;;AU).  The first field tells you what type of ACE it is – either A for allow or D for deny.  The next field lists any ACE flags that specify whether this ACE is an inherited ACE prorogated down from a parent object and if and how this ACE should propagate down to child objects.  The only flag in this ACE is ID which means the ACE is in fact inherited.  The next field lists the permissions this ACE allows or denies.  In this example FA stands for all file access rights.  The next 2 fields, Object Type and Inherited Object Type,  are always blank on file system permissions (hence the 3 semicolons in a row); they are only used places like Active Directory where there are different types of objects (user, group, computer, etc) that you can define permissions for.  Finally, the last field is Trustee and identifies the user, group or special principal begin allowed or denied access.  Here you will either see the SID of the user or group if the ACE applies to a so-called “well-known” SID you’ll the corresponding acronym.  In this example AU stands for Authenticated Users.

Event ID 4670 does a great job of alerting you when permissions change on an object and telling you which object was affected and who did it.  To go further and understand what permissions where actually changed you have to dive into SDDL.  I recommend Ned Pyle’s 2-part TechNet blog, The Security Descriptor Definition Language of Love for more information on SDDL.