Hmm.

From GCN:

“This is a change we have not faced in the IT security industry before,” he added.

The closest parallel has been in the Defense Department, which anticipated OMB’s reaction in this area. DOD’s Directive 8570 on information assurance, approved in December 2005, requires all of the department’s information assurance workers to obtain an accredited commercial certification in computer security. DOD has approved 13 certifications for the directive.

The DOD requirement already has thrown what one conference attendee called a giant monkey wrench into the IT security manpower market.

“If OMB issues a similar requirement, it’s going to throw the supply and demand curve even more out of balance,” he said.

Datesman agreed, saying it probably would take years for the supply of certified workers to catch up with demand. A CISSP certification requires five years’ experience. “You don’t mint them out of college,” he said.

OK, this is where this trolley leaves the track. I have met CISSP certified folks that I would wager they’d be lucky to fight their way out of a wet paper bag. “Don’t mint them out of college” is a phrase that I’d argue. I would offer that the ISC2 should start auditing certified members. The validity of the CISSP cert is becoming diluted in the eyes of the market.

A picture is worth a thousand words.

It’s great for the mandatory HR tick box but, how many of these folks actually have the ability? Sure they can memorize some flash cards and pass a test but, are they effective? Some, not so much.

On the face of it this is a good idea.

Like all good intentions, they make great paving stones on the road to hell.

Article Link

At TechEd this year, I gave a presentation called "21st century networking: time to throw away your medieval gateways." (Actually, I've given this same talk before, at events in Amsterdam, Brussels, Oslo, and numerous on-campus customer meetings. It's time to bring the knowledge to the masses.)

I described an idea of using IPv6, IPsec, NAP, and group policy to build a pretty slick replacement for clunky VPN gateways. Turns out we've been piloting this very idea on our internal corpnet. Like a good little bunny I got myself enrolled in the thing and -- pardon the unattractive gushing -- this thing rawks! Here's a brief rundown of the parts you'd configure on managed clients:

• Windows Vista Business (with Software Assurance), Enterprise, or Ultimate editions
• That are domain-joined
• Users run as non-admin
• Group policy applies numerous settings
• UAC is enabled
• BitLocker is configured to protect confidential information stored offline
• The Windows Firewall is enabled
• NAP is used for checking health
• Forefront Client Security for keeping malware off the box
• Smart cards for strong authentication of users
• IPsec is required for connection authentication and traffic encryption
• IPv6 is required for worldwide Internet connectivity
• A DNS suffix search list represents the data center name space
• Static IPv6 DNS servers provide name resolution for hosts in the data center

What does this give you? True anywhere access, anywhere in the world, directly to corpnet resources from managed and secure client PCs. The Internet has replaced private WAN links for good reason: enormous cost benefits. The only thing holding us back from fully utilizing this development has been a lack of way to enforce and monitor the security of clients not physically located within the corpnet. Well, those days are over. Now you can build PCs that are trusted just as if they were on the corpnet, without knowing or caring anything about the underlying network connections. And let me tell you, it's as addictive as a few other substances I could mention, but will refrain, since this is (I hope) a family blog :)

Maybe you've heard of the notion of "deperimeterization." Taken to its extreme, I think it's a bit silly. To put a SQL Server directly on the Internet is just plain stupid -- not because I don't think I could keep it protected, but simply because that's unnecessary risk. Only my web server -- and no one else -- should be talking to my SQL Server. But that web server will be in the same subnet as the SQL Server, and IPsec policies used also here will govern who can connect to the SQL Server. Warning to any and all network DMZs: your days are numbered!

Shrink your perimeter to that which really matters -- your data center. All your clients live (as we would say in the olden days) "on the outside of the firewall." Now then, there are two kinds of clients. Managed clients, as I described above, establish IPsec-authenticated/encrypted, group-policy-configured, NAP-enforced IPv6 connections directly to corpnet resources without going through any kind of access gateway. The router connecting you to your ISP is fully sufficient for blocking denial of service attempts. Be sure to follow my advice in "Configure your router to block DOS attempts," and then add two more rules to permit incoming port udp/500 and IP protocol 50 over IPv6. That's it. No NATing or other unnatural network acts are required (finally, you can stop lying to your significant other about why you squirrel yourself away in the computer room all those weekend nights).

Unmanaged clients will continue to use IPv4 to access published Web and Win32 applications through a gateway like IAG. Since you can't trust these clients nor can you trust the data they're throwing at you, you have to inspect and validate at the perimeter. You can take advantage of IAG's application-modifying capabilities to "wrap" security around poorly-written web apps; you can even download an ActiveX control to unmanaged clients to perform some basic health checking, policy enforcement, and cache clearing. None of these eliminates the final requirement to continue inspecting and removing malware from servers where users store data: Exchange, SharePoint, Office Communications Server, and file servers.

Machines are mobile, data is mobile. The mainframes and large desktop PCs of the past posses an effective security attribute: the heaviness of the machines. You couldn't easily saunter out the front door with a PC-AT in your pocket! These days, we all line our pockets with tiny little mobile phones stuffed with 16GB of storage. It's now a fact: data moves. And like water, data moves wherever it can, as rapidly as it can, often beyond your control if you don't prepare for that. With properly-configured and managed clients we can enjoy a single access and authentication experience no matter where the computer is physically located. For example: I can sit in my house and enter '"http://internal-web-site-name" in my browser. The DNS suffix search list adds the appropriate suffix, my browser's resolver performs an IPv6 name lookup, and my computer makes an authenticated and encrypted connection, after it meets the NAP policy, directly to that internal server. Very nice. As far as I'm concerned, there's no difference between the Internet and my corpnet. It's all just there.

For a while now many of you know I've been speaking and writing, mostly at the conceptual level, about the day when such a way of remote computing will arise. Well, my friends, that day is now. You can indeed build it now, with the products you have. I won't admit it's all peaches and cream: there's a fair number of moving parts here, it's true. But most of these moving parts are parts you're already familiar with: I'm simply encouraging you to move them in a specific way. You'll need to do some custom scripting for client-side connection diagnostics, but that's about it.

My next step is to create a more detailed guide, which I plan to publish through TechNet Magazine. I'm targeting (but not promising) the October issue. The article will include greater details about configuring your infrastructure to support the managed clients I describe.

I've lost track of the swelling number of individual conference attendees and the plethora of email writers who've expressed a desire to build this in their own environments. The one common thread from everyone is "I want to do it now!" Folks, it's really pretty exciting for me to see so many of you ready to cross the chasm from the perdition of paleo-networking (layer upon endless, complex layer of DMZs) into the paradise of flat, simple, cheap, and secure access to information. If you haven't yet, please take the time to read through some of our information (especially Scott Charney's paper) on end-to-end trust. Friends, the idea I describe above is the plumbing for realizing the end-to-end trust vision.

• Conduct regular security assessments of Web-based applications. The universities first need to determine how many Web-based applications they have and then make provisions to regularly update their lists of applications.  They then need to develop and implement procedures for regularly conducting security reviews of their critical Web-based applications.

• Develop a university-wide policy and associated procedures for updating Web servers, which are computers that host Web-based applications. Software vulnerabilities are constantly being discovered and publicized, and the universities need to develop or enhance: (1) procedures for identifying vulnerabilities relevant to their Web servers, (2) a timeline for reacting to notifications of newly discovered Web server vulnerabilities, and (3) a process for determining whether to apply a software update, establish another control to address the Web server vulnerability, or accept the risk of not updating the software.
• Ensure that security is built into the process for developing Web-based applications. According to ASU, UA, and NAU officials, none of them have university-wide security standards for developing applications. According to an IT best practice, building security into the development process is more cost-effective and secure than applying it afterwards.
• Provide training to application developers so that they are aware of common Web-based application vulnerabilities and methodologies that can be used to avoid them. None of the universities have a training program that is mandatory for all users and geared toward an individual's role within the university.
  

The database itself has very little awareness of where the application that made the connection is located.  It does not necessarily know the purpose of the application.  It may or may not know the real user who is using that connection.  It’s not that it cannot, it is just typically not programmed to do so.  It is at the beck-and-call of the application and will do whatever the application asks it to do.

One of the great reasons to use Database Activity Monitoring  is to de-mystify that connection.  These monitoring tools are going to pay close attention to where the connection is coming from, what application is making the connection, what time of day is, how much data is being moved, what queries are being run, what fails to execute, and on and on.  This provides a very real benefit in detecting attacks or other types of mis-use.   There is a strong market for this type of tool because the application developer did not develop this code within the context of the service they are providing. 

Can this be done from within the database?  Yep.   Do people do this?  Rarely to never.  Should it be done?   I contend that to some degree it should always be there.  Much in the same way we provide range checking on database values, we should also have some degree of business consistency checking.  But we don’t because it is typically not part of the scope of the application project to program the database to perform additional checking and verifications.  Usually it is only scoped out to store data and provide some reports, just a basic repository for storage of data and application state.   We have gotten to the point where we use Hibernate (http://www.hibernate.org/) to abstract the concept of a database altogether and further remove any native database visibility.  

Give the database user name and password and it will give you everything you have permissions to do … and then some.   It is set up to trust you.  And why not, you have it the right credentials!  And the converse of that is the application developer views the database as some abstract object.  Security of that object is someone else’s problem.  The loss of visibility does not mean that the functionality is not there, or that it is not important, or that the application developer can ignore it.

 What I am trying to say is the database is set up to trust the application connection and it should not.

 Whatever you gave the user who connects permission to do, it will do, whenever asked.  But should you be accepting local connections?  Remote connections?  Ad-hoc queries?  What stored procedure execution is appropriate?  If the database is used in an SOA environment, or the omnipresent ‘hub-and-spoke’ model, how do those rules change per application connection?  And unless you instruct the database to do more, to question the authenticity of the connection over and above access rights, it will not provide you any additional value in terms of security, data consistency or data privacy.  Why is it that application security, and quite specifically web application security, viewed soley as a web application security problem?  The application has strong relationship with the database but typically does not have bi-directional trust enforcement or security.   

For example, in production database environments we had a requirement that there would be no ad-hoc access under normal usage of the system.  We would implement login triggers similar to NoToad.sql  to prohibit this access via an ad-hoc administration tool.  We had stored procedures built into our packages that recorded an audit event whenever a user was selecting more than some predetermined number of customer rows.  But I think this was atypical, and these types of security constraints are not systemic, meaning they are oft left out of the back end design. 

The application is designed to serve a business function and we buy security products to monitor, assess and audit the business function externally. 

Do you see where I am going with this? We can build security in systemically if we choose to do so and reduce the dependency on external security.  We can and should do more to verify that the application that is connecting to the database not only has appropriate credentials, but appropriate use. A database is an application platform, and an application in and of itself. This becomes even more important in a virtualized environment where some of the underlying network assumptions are thrown out the window.  Hackers spend a lot of time determine how best to access and utilize the database because it not only contains the information they typically are after, but it is an extraordinarily complex, feature rich platform.  That means a fertile field of opportunity for misused trust relationships and insecure functions … unless you program the database to perform these verifications.  

The database itself has very little awareness of where the application that made the connection is located. It does not necessarily know the purpose of the application. It may or may not know the real user who is using that connection. It’s not that it cannot, it is just typically not programmed to do so. It is at the beck and call of the application and will do whatever the application asks it to do.

One of the great reasons to use Database Activity Monitoring is to de-mystify that connection. These monitoring tools pay close attention to where the connection is coming from, what application is making the connection, what time of day it is, how much data is being moved, what queries are being run, what fails to execute, and on and on. This provides a very real benefit in detecting attacks and other types of misuse. There is a strong market for this type of tool because application developers rarely develop this capability within the context of the service they are providing.

Can this be done from within the database? Yep. Do people do this? Rarely to never. Should it be done? I contend that to some degree it should always be there. Much in the same way we provide range checking on database values, we should also have some degree of business consistency checking. But we don’t because it is typically not part of the scope of the application project to program the database to perform additional checking and verifications. Usually it is only scoped out to store data and provide some reports, just a basic repository for storage of data and application state. We have gotten to the point where we use Hibernate <http://www.hibernate.org/> to abstract the concept of a database altogether and further remove any native database visibility.

Give the database user name and password and it will give you everything you have permissions to do … and then some. It is set up to trust you. And why not, you gave it the right credentials! And the converse of that is the application developer views the database as some abstract object. Security of that object is someone else’s problem. The loss of visibility does not mean that the functionality is not there, or that it is not important, or that the application developer can ignore it.

What I am trying to say is the database is set up to trust the application connection and it should not be.

Whatever you gave the user who connects permission to do, it will do, whenever asked. But should you be accepting local connections? Remote connections? Ad-hoc queries? What stored procedure execution is appropriate? If the database is used in an SOA environment, or the omnipresent ‘hub-and-spoke’ model, how do those rules change per application connection? And unless you instruct the database to do more, to question the authenticity of the connection over and above access rights, it will not provide you any additional value in terms of security, data consistency, or data privacy. Why is it that application security, and quite specifically web application security, is so often viewed soley as a web application security problem? The application has a strong relationship with the database but typically does not have bi-directional trust enforcement or security.

For example, in production database environments we had a requirement that there would be no ad-hoc access under normal usage of the system. We would implement login triggers similar to NoToad.sql to prohibit this access via an ad-hoc administration tool. We had stored procedures built into our packages that recorded an audit event whenever a user was selecting more than some predetermined number of customer rows. But I think this was atypical, and these types of security constraints are not systemic, meaning they are often left out of the back end design.

The application is designed to serve a business function and we buy security products to monitor, assess and audit the business function externally.

Do you see where I am going with this? We can build security in systemically if we choose, and reduce the dependency on external security. We can and should do more to verify that the application that is connecting to the database not only has appropriate credentials, but appropriate usage. A database is an application platform, and an application in and of itself. This becomes even more important in a virtualized environment where some of the underlying network assumptions are thrown out the window. Hackers spend a lot of time determining how best to access and utilize the database not only because it typically contains the information they are after, but also it is an extraordinarily complex, feature rich platform. That means a fertile field of opportunity for misused trust relationships and insecure functions … unless you program the database to perform these verifications.

So it looks my hot topic this week is how full of beans most vendors are and how it is making life difficult for security admins looking to choose the right product.  I already wrote about how some vendors claim customers use their products for functions that they do not. I wrote about how customers are hounded by sales people calling and writing, blowing smoke about products and solutions they don't want.  BTW, on a comment to that one, Greg Ness writes a very insightful piece that I want to paste in here:

I think we're seeing the tale end of the era of "entrapment marketing" whereby someone downloads a white paper or watches a webcast and then gets swamped with calls from salespeople. As a marketing VP I get about 5-6 calls a day. They're so disruptive that I've turned my ring off and batch process the calls once a week.

I think the quantity and quality of the traditional downloads has declined since the early 2000s, so that real people get even more calls than they used to. I've become a big believer in social media (no registration required) and inbound registration/interest.

I have a netsec blog at: www.archimedius.net where I talk about issues. I launched it last year after seeing our google analytics scores register large social media inbound traffic to our website. Three top blogs were generating equivalent visitor eyeball minutes on our website to leading pubs.

Social media is less disruptive, usually is part of a broader, real-time technology conversation and helps you to establish better relationships with prospects, all in exchange for sharing your view of the world.

Now I was reading a recent analyst report on NAC and almost choked when I saw some of the data passing for information in this report. To be fair the analyst does preface their report by saying they can't vouch for any of the factual information supplied by vendors,  But my God does anyone tell the truth anymore?  Funny thing is it is the usual suspects up to their same old, same old fudging their numbers. 

So not only do we have misleading press releases talking about customers who don't really use the products as announced, we have analyst reports that have glaring factual errors that are not checked and people rely on and customers who are swamped with slick sales people.  What can we do as an industry to bring sanity to all of this?  Am interested in what your take on all of this? Is security marketing worth the paper it is written on anymore?

So it looks my hot topic this week is how full of beans most vendors are and how it is making life difficult for security admins looking to choose the right product.  I already wrote about how some vendors claim customers use their products for functions that they do not. I wrote about how customers are hounded by sales people calling and writing, blowing smoke about products and solutions they don't want.  BTW, on a comment to that one, Greg Ness writes a very insightful piece that I want to paste in here:

I think we're seeing the tale end of the era of "entrapment marketing" whereby someone downloads a white paper or watches a webcast and then gets swamped with calls from salespeople. As a marketing VP I get about 5-6 calls a day. They're so disruptive that I've turned my ring off and batch process the calls once a week.

I think the quantity and quality of the traditional downloads has declined since the early 2000s, so that real people get even more calls than they used to. I've become a big believer in social media (no registration required) and inbound registration/interest.

I have a netsec blog at: www.archimedius.net where I talk about issues. I launched it last year after seeing our google analytics scores register large social media inbound traffic to our website. Three top blogs were generating equivalent visitor eyeball minutes on our website to leading pubs.

Social media is less disruptive, usually is part of a broader, real-time technology conversation and helps you to establish better relationships with prospects, all in exchange for sharing your view of the world.

Now I was reading a recent analyst report on NAC and almost choked when I saw some of the data passing for information in this report. To be fair the analyst does preface their report by saying they can't vouch for any of the factual information supplied by vendors,  But my God does anyone tell the truth anymore?  Funny thing is it is the usual suspects up to their same old, same old fudging their numbers. 

So not only do we have misleading press releases talking about customers who don't really use the products as announced, we have analyst reports that have glaring factual errors that are not checked and people rely on and customers who are swamped with slick sales people.  What can we do as an industry to bring sanity to all of this?  Am interested in what your take on all of this? Is security marketing worth the paper it is written on anymore?

The solution to the above problem is very useful in practice — in fact, so useful that it spawns a lot “fights” over patents. Many techniques were patented, including the well-known Encrypted Key Exchange (EKE) and Simple Password Exponential Key Exchange (SPEKE). A secondary problem is technical; both the EKE and SPEKE protocols have subtle but worrying technical limitations (see the paper for details).

At the 16th Workshop on Security Protocols held in April 2008, Cambridge, UK, I presented a new solution (joint work with Peter Ryan) called Password Authenticated Key Exchange by Juggling (or J-PAKE). The essence of the protocol design inherits from the earlier work on solving the Dining Cryptographers problem; we adapted the same juggling technique to the two-party case to solve the PAKE problem. To our best knowledge, this design is significantly different from all past PAKE solutions.

Intuitively, the J-PAKE protocol works like a juggling game between two people — if we regard a public key as a “ball”. In round one, each person throws two ephemeral public keys (”balls”) to each other. In round 2, each person combines the available public keys and the password to form a new public key, and throws the new “ball” to each other.

After round 2, the two parties can securely compute a common session key, if they supplied the same passwords. Otherwise, the protocol leaks nothing more than: “the supplied passwords at two sides are not the same”. In other words, one can prove his knowledge of the password without revealing it. A Java implementation of the protocol on a MacBook Pro laptop shows that the total computation time at each side is merely 75 ms.

We hope this protocol is of usefulness to security engineers. For example, compared with SSL/TLS, J-PAKE is potentially much more resistant against phishing attacks, not to mention that it is PKI-free. Since this protocol is the result of an academic research project, we didn’t — and have no intention to — patent it. As explained in the paper, J-PAKE even has technical advantages over the patented EKE and SPEKE in terms of security, with comparable efficiency. It has been submitted as a follow-up to the future extension of IEEE P1363.2.

We believe the PAKE research is important and has strong practical relevance. This post is to facilitate discussions on this subject. The paper can be viewed here. Any comments or questions are welcome.