standards

You are currently browsing the archive for the standards category.

Specialized Security – Limited Functionality

November 15, 2007 in security, standards, vista by Daniel Nyström | No comments

I’m not an advocate or fan of Microsofts technology, implementation of standards or politics. That’s for sure. However this is actually really interesting for us that are stuck in our corporate environment with Windows:

I was recently visiting a larger company in Sweden that is in the testing stage of a large deployment of Windows Vista. This deployment will be done on a pretty big userbase that has somewhat special security demands and for that reason they are following the SSLF (or SS-LF) baseline presented by Microsoft in the Windows Vista Security Guide. In that same guide you will also find information about a lighter security model called Enterprise Client (EC). The EC-baseline provides a more simple and less intrusive security baseline but it did not fill the requirements for this particular company.

I was quite impressed with the work they had done and how well it seems to have fallen out and decided to read up on these baselines. I mean, more security for Windows systems is not a bad thing and if you can do this easily then it would be great.

The definition of the two baselines in the Windows Vista Security Guide are:

  • Enterprise Client (EC). Client computers in this environment are located in a domain that uses Active Directory and only need to communicate with systems running Windows Server 2003. The client computers in this environment include a mixture: some run Windows Vista whereas others run Windows XP….
  • Specialized Security – Limited Functionality (SSLF). Concern for security in this environment is so great that a significant loss of functionality and manageability is acceptable. For example, military and intelligence agency computers operate in this type of environment. The client computers in this environment run only Windows Vista…”

The whole process of securing the clients are done via Active Directory group policies and the implementation of these can be very much simplified by using pre-made scripts (also included in the security guide).

The main downside for me with this policy (SSLF) is that it might cause a minor conflict with the brand new “Panda For Desktops” (formerly known as ClientShield) but there is an easy remedy for that particular problem. Guess why I was there btw ;) hehe…

Here is a short list of resources for more information:

And as a bonus, the delicious, the enormously useful (as not many run on an SSLF baseline) but also quite CTO friendly:

This should be an prerequisite for all administrators running a +100 user network. Sure would make my life a hell of a lot easier during intrusion investigations ;)

Cheers and drive safe (winter in Sweden now) !

Tags: , , , , , ,

“Deterministic Random Bit Generators”, big trouble

November 15, 2007 in cryptography, security, standards by Daniel Nyström | No comments

Bruce Schneier on one of the “Deterministic Random Bit Generators” supplied by the U.S. government:

“But today there’s an even bigger stink brewing around Dual_EC_DRBG. In an informal presentation (.pdf) at the CRYPTO 2007 conference in August, Dan Shumow and Niels Ferguson showed that the algorithm contains a weakness that can only be described a backdoor.”

To copy common phrasing of the author himself, This is a big deal.

Find the whole article here.

 

PCI DSS, err… C(as in circumventable)DSS

November 12, 2007 in networking, programming, standards, webapps by Daniel Nyström | No comments

I downloaded and listened in on the web application security talk that Jeremiah Grossman (WhiteHat Security (coordinators of the talk), Robert “RSnake” Hansen (SecTheory), Chris Paggen (Cisco) and Jordan Wiens (Network Computing) had. This was an unscripted roundtable discussion and it was very interesting to me, as I’m not so skilled in the areas that they discussed (getting there, more on that in later posts). Full info on the talk can be found at:

http://jeremiahgrossman.blogspot.com/2007/11/live-online-roundtable-episode-1.html

For me, the part of the talk dealing with WAF’s (web application firewalls) and normalization of input was quite interesting. As discussed, there really is no good way to do it if the customer or developer do not know they way his server and webapps handles input (and output for that matter) and which features are needed. However, if there is good documentation of the webapp that is to be protected, you might get away with some normalization (and then why not do it). WAF’s in general is not something you “just plug in” and some more fine tuning will most likely be needed if normalization is something that you want to do.

Another thing that i thought was actually more interesting, was hearing these people that are specialists on web security discuss the PCI DSS and what their experience and comments on it were.

One good thing with the PCI DSS is that for an CTO/Administrator/Security engineer that is really dedicated to providing good security for his company and it’s clients, the standard can be used to push up security budgets and raise awareness in upper-management. However, the money will also have to be well spent, and that’s where some of the participants see a problem.

That problem is that companys and departments with dedicated budgets will try to hold down costs, sometimes even if they have the money needed for a thorough security solution, all for increased profit. This in turn might lead them to cheaper and less reliable certified scanners and vulnerability testers, that might not find holes where there actually are plenty. What does this lead to? Well, not much for those trying to fill the PCI’s requirements, as they will still pass (AND with no problems detected, wohooo). The cost, as usual, ends up with the customer that gets his or hers creditcard-data stolen from the site.

An update on this were posted by RSnake (one of the participants) on the 11/11-07.

Another topic regarding the PCI DSS that was discussed was it’s unclarity in certain paragraphs that might lead to total or partial circumvention of the upholding of the standard. No comments regarding this but it does indeed sound pretty serious if that’s the case ;)

More information on the PCI DSS here. And I also recommend you all to visit the link in the top of this post and listen to the whole webinar.

Cheers,

Tags: , ,

Newer entries »