[SecurityRatty] tag: enforce

Dems were for Web 2.0 before they were against it

Tue, 15 Jul 2008 16:57:29 +0000

zenpundit aka Mark Safranski on the congressional Democrats war on Web 2.0

Nor was one of the leading Web 2.0 experts, Clay Shirky, reassured either, writing at
Open House Project: “They can enforce it the way we enforce parking rules, which is to miss most violations, and then bring in draconian enforcement of enough violations to have a chilling effect. This will also allow the Rules Committee to wield enforcement selectively as a stick.” Representative Capuano, who has described the internet as “a necessary evil,” would be one of the enforcers and he is part of a larger Democratic House leadership whose speaker, Nancy Pelosi, also supports a revival of the long-defunct “Fairness Doctrine” that made it unprofitable for broadcast networks to permit robust political expression on air.

...

More ominous still would be the precedent of the U.S. government designating “official” external websites — imagine having the power to select “official” newspapers — that would have to hew to House regulations and be as free as possible from political or commercial advertising. Given the ubiquity of blogads, most blogs, bulletin boards, and discussion forums would be shut out of the conversation with our nation’s elected officials. Essentially, Capuano is demanding that the internet adapt itself to the House of Representatives instead of the House adapting to the reality of the internet.

Looks like a good diversion from normal critical DC wealth destroying activities, and baseball steroid and NFL team filming practices investigations,

D.C. Police Detective Arressted for Propositioning a "Prostitute".

Sat, 12 Jul 2008 14:58:00 +0000

Some time clients call us up and ask if we can send them off-duty cops for Executive Protection assignments. My first inclination is to tell them why we are reluctant to use off-duty police.

Yesterday, WTOP radio reported that a Detective Wheeler from the Washington D.C. Metropolitan Police had been arrested for trying to hire a Prostitute. Unfortunately for Detective Wheeler, the "prostitute" was an undercover Police Detective herself.

The story gets better, however. It seems that Detective Wheeler is assigned to the Vice Unit. For those of you who don't know what a Vice Unit does, they set up "stings" and dress female Police officers to look like prostitutes in order to arrest those who try and do business with "prostitutes". One wonders if Detective Wheeler should be charged with the prostituion charge or one involving gross stupidity.

Just becaause a Police officer carries a gun, does not mean that this qualifies him or her to do everything security related. While most of them are decent, hard working indivduals, there are also some who break laws and circumvent the system for their own benefit. When you hire an "off-duty cop", you do not know what you are getting. Perhaps you will get a bad apple(s) who will do more harm than good. Afterall, what way is there to vet them?

A professional security company like ours, train their own people and enforce from day one a strong sense of Ethics. We have a zero policy for any behaviour that might be detrimental to us or the client. On the rare occassion when someone does something that we do not condone, they are terminated. There is no room for Union intervention or "three strikes, you're out" or any other delaying tactic.

Our reputation is too important. Then again, we do not have "jobs for life" but must instead earn buisness by constantly performing. The next time you need a security person, keep this in mind.

OWASP Talk Q&A Notes

Fri, 11 Jul 2008 11:36:26 +0000

On Monday I did a talk on Web Services security at the MSP OWASP. The talk was ok, but not as good as at RSA because I Brian Chess did a better job with some of the stories than me. What was really good though was a number of questions and answers afterwards.

One person asked the old chestnut - "do we need to care about web services security if we are inside the firewall?" Now, I have heard this question many, many times in different ways, and this time my brain just shorted out, I basically said that I am not sure what difference it really makes. You don't get security from a firewall, you may get the ability to fire someone if they do something bad, but in most companies there is no "wall" and there sure isn't any "fire", at most they are speed bumps. I am *not* saying to remove them, they are part and parcel of how you operate a network but they are not really providing any additional security. Network firewalls are thought of as a security tools because they began as a security innovation and they are paid for out of the security budget.

Robert Garigue said several years ago that network firewalls are part of network hygiene like brushing your teeth. Information security should not have to help people brush their teeth, and instead should operate like a dentist helping groups work more complex and risky issues. I have advised CISOs at several companies to off load the network firewall jockeys out of infosec and into network groups. Sometimes they listen. If so, the infosec group can focus on other issues instead of managing a Visio-driven "security" device.

Why Visio? Well, the main security property from a firewall is the scary flames and brick wall on Visio. And how do you know whether or not to open up a port? You just open the org chart (in Visio) and find the level of the person who is requesting the port be opened. If VP Then Yes. Is this security? Hardly.

So one last time - Web Services are used to provide access to your main systems (which live on mainframes, big RDBMS, SAP, ERP, CRM, and so on) these are the keys to the kingdom, and lots of apps need them. The whole point of Web Services is to make it easier to talk to them. So "inside" or "outside" the firewall, do you need to care about authentication, authorization, and auditing on the systems that run your entire business???

Another interesting question from the Q & A from Jon Passki was on XML Security Gateways. We talked a fair bit about their utility in solving the aforementioned authentication, authorization, and auditing problems. I pulled up Vordel's gateway and showed how to build security workflows to deploy security as a service. Jon asked could I ever imagine a Web services security architecture without a gateway? I said I think that they are not always the starting point but mid to long term they are definitely in basically any effective security architecture I can think of. Having a place to deploy, manage, and enforce policy that is separate the code solves a lot of real world problems. People are hung up on thinking about Web services programming like it has to be Web app programming (this happens in REST a lot), but there is another school of successful web apps, arguably the most successful, and its called email.

Email app architecture looks nothing like web app design. You wouldn't read every email sent to your address would you? Of course not, it goes through spam filters, virus checkers and so on. Further its a message oriented paradigm, and you know that unless its signed/encrypted with PGP/GPG security is suspect at best. So yeah, I think gateways are an hugely important part of a Web Services security architecture.

Finally, I can also not imagine going live when you are supporting multiple protocols and token types without a good testing strategy. Mark O'Neill recently blogged something I recommend to all my clients - namely make sure you have security specific test cases, test harnesses and testing tools, like for example Vordel's Soapbox.

Kill Switches and Remote Control

Tue, 01 Jul 2008 02:48:37 +0000

It used to be that just the entertainment industries wanted to control your computers -- and televisions and iPods and everything else -- to ensure that you didn't violate any copyright rules. But now everyone else wants to get their hooks into your gear. OnStar will soon include the ability for the police to shut off your engine remotely. Buses are getting the same capability, in case terrorists want to re-enact the movie Speed. The Pentagon wants a kill switch installed on airplanes, and is worried about potential enemies installing kill switches on their own equipment. Microsoft is doing some of the most creative thinking along these lines, with something it's calling "Digital Manners Policies." According to its patent application, DMP-enabled devices would accept broadcast "orders" limiting capabilities. Cellphones could be remotely set to vibrate mode in restaurants and concert halls, and be turned off on airplanes and in hospitals. Cameras could be prohibited from taking pictures in locker rooms and museums, and recording equipment could be disabled in theaters. Professors finally could prevent students from texting one another during class. The possibilities are endless, and very dangerous. Making this work involves building a nearly flawless hierarchical system of authority. That's a difficult security problem even in its simplest form. Distributing that system among a variety of different devices -- computers, phones, PDAs, cameras, recorders -- with different firmware and manufacturers, is even more difficult. Not to mention delegating different levels of authority to various agencies, enterprises, industries and individuals, and then enforcing the necessary safeguards. Once we go down this path -- giving one device authority over other devices -- the security problems start piling up. Who has the authority to limit functionality of my devices, and how do they get that authority? What prevents them from abusing that power? Do I get the ability to override their limitations? In what circumstances, and how? Can they override my override? How do we prevent this from being abused? Can a burglar, for example, enforce a "no photography" rule and prevent security cameras from working? Can the police enforce the same rule to avoid another Rodney King incident? Do the police get "superuser" devices that cannot be limited, and do they get "supercontroller" devices that can limit anything? How do we ensure that only they get them, and what do we do when the devices inevitably fall into the wrong hands? It's comparatively easy to make this work in closed specialized systems -- OnStar, airplane avionics, military hardware -- but much more difficult in open-ended systems. If you think Microsoft's vision could possibly be securely designed, all you have to do is look at the dismal effectiveness of the various copy-protection and digital-rights-management systems we've seen over the years. That's a similar capabilities-enforcement mechanism, albeit simpler than these more general systems. And that's the key to understanding this system. Don't be fooled by the scare stories of wireless devices on airplanes and in hospitals, or visions of a world where no one is yammering loudly on their cellphones in posh restaurants. This is really about media companies wanting to exert their control further over your electronics. They not only want to prevent you from surreptitiously recording movies and concerts, they want your new television to enforce good "manners" on your computer, and not allow it to record any programs. They want your iPod to politely refuse to copy music to a computer other than your own. They want to enforce their legislated definition of manners: to control what you do and when you do it, and to charge you repeatedly for the privilege whenever possible. "Digital Manners Policies" is a marketing term. Let's call this what it really is: Selective Device Jamming. It's not polite, it's dangerous. It won't make anyone more secure -- or more polite. This essay originally appeared in Wired.com.

Symantec's Network-Based NAC

Sun, 29 Jun 2008 23:33:00 +0000

Yes, you read it right- Symantec (as in the software vendor) has a network-based (as in the hardware) NAC. Once you get over the title, keep reading.

If you read my blog, or know me, you probably know I do NOT like software (and it usually doesn’t like me). So, I’d be the first to jump on the ‘anti-software-peer-based-NAC’ train, but I think we have to be informed before we jump to conclusions and hop on any trains.

Mirage’s recent blog post on Symantec’s ‘Silly SNAC’ was certainly a result of a mis- (or un-) informed person. Tim did a much better job on his mention of SNAC in the NWW blog, but all the dots still aren’t connected. It proves the point that sometimes we (as bloggers) tend to write based on a feeling and sometimes don’t dig for the fact.

So, in an effort to make sure I understood this new peer-based NAC, I reached out to Patrick Wheeler, Symantec’s Senior Product Manager for Network and Endpoint Security. Based on my conversations with him, and a pretty detailed investigation into the options and configurations of their NAC products, I have some slightly more informed opinion to share with you now.

Symantec has a variety of NAC enforcement components and options. I’m going to keep all the software-type-stuff out of this conversation for the time being. They have (among other things) the NAC Enforcer, an appliance similar to the other NAC controllers we see from traditional hardware vendors. Just like it’s counterparts, Symantec’s NAC Enforcer can be configured for DHCP, inline or 802.1X based enforcement.

The piece that’s different is the integration of the NAC Enforcer with Symantec’s Endpoint Protection Manager server that hosts the policies for the NAC. It’s similar to the management-enforcement configuration we see from other vendors, only the management piece is housed on a server instead of another appliance.

And, just as other vendors offer some type of endpoint integrity agent, the Symantec agent comes in the form of the Symantec NAC Client, which can be used by itself, or integrated with the Symantec Endpoint Protection Client for an even more robust feature-set. (The Endpoint Protection Client offers some additional host-based firewall features that the NAC can leverage).

So, what about the Peer-Based NAC? Ah, well that’s just the first iteration of a ‘vision’ to address mobile corporate users. If employees have laptops in an ad-hoc situation outside of the enterprise infrastructure (and therefore, outside of enterprise enforcement), then the peer-based NAC can port the enforcement rules set at the ‘mothership’ and enforce them individually. The peer-based NAC can protect mobile assets in their most vulnerable situation, outside the security of the corporate network. But, the rules are still set centrally and the peer-based NAC was designed to be just one step towards an added layer of protection, not as a replacement for network-based NAC.

For now, I’ll stay off the hate train, since the peer-based NAC is more of a supplement to a more robust traditional NAC solution. If they move to a fully-host-enforced product, I’ll buy my tickets…

Image shown is copyright of Symantec Corporation.

# # #

Maybe the NAC used car salesman can claim them as a customer too? In NAC quality counts!

Fri, 27 Jun 2008 19:36:27 +0000

Dark Reading had a good article today talking about GuideWorks, the TV Guide/Comcast joint venture's 2 year odyssey with NAC, which finds them finally starting to see some good results. I immediately went to the website of the NAC used car salesman to see if they claimed them as a NAC customer too, but didn't see anything yet. But with those guys you never know.

Seriously though folks, this story is a classic NAC story. GuideWorks had guests and unmanaged users visiting their offices all the time. When they would ask to plug in they were told sorry, wait till you get back to your hotel. Over time this answer became unacceptable and they realized they needed a way to give these people a way to get on the net and get their email while keeping their network secure. This very same need drives many initial NAC deployments.

Like many other NAC customers they wanted something easy, not add major overhead or network changes and easy to administer. Again straight out of the NAC playbook. In the Summer of '06 they began a pilot of the Tipping Point NAC product which is based on the old Roving Planet technology. Now Roving Planet was more of a wireless security company, but near the end they rebranded themselves as NAC and Tipping Point uses that with their IPS devices to enforce. Best of all for GuideWorks the price was sub 10k.

Here is where the other side of NAC comes in. This is what the article says:

While NAC tools are often advertised as plug-and-play, GuideWorks found that the NAC setup required a high level of networking expertise. Fortunately, the Inglewood site had plenty of technical expertise because that’s where many of the company’s developers are stationed. In addition, GuideWorks put one of its front-desk employees in charge of setting up new accounts. But because her technical background was limited, the company had to walk her through a learning curve.

Now the company is planning to deploy the system at its Radnor office, which will be a bit more challenging since there’s less technical expertise there, and that office gets a greater number of visitors. So GuideWorks has been on the search for employees to support the NAC system there. The company expects to have NAC up and running there by the end of the summer.

So 2 years after trial they are rolled out in one office and have to hire employees to support the NAC system at the next office. This was a problem with many of the failed NAC companies over the last few years and I think the problem with this Tipping Point solution. Just providing guest access should not be that hard! Yes the StillSecure Safe Access solution would have been much easier and faster to implement, but to be fair, any of the leading NAC solutions would have been up and running easier as well.

While this article was supposed to serve as reference and case study for the Tipping Point NAC solution, it is far from inspiring. If I were a customer looking into NAC, I don't think this would make run out and look at the Tipping Point solution. Moral of the story is, just because you made a good IPS doesn't mean you have a very good NAC product. When it comes to something like NAC, quality counts and buying a 2nd tier solution can cost you in time to implementation and total cost of ownership.

Security Matters: I've Seen the Future, and It Has a Kill Switch

Thu, 26 Jun 2008 00:00:00 +0000

OnStar will soon include the ability for the police to shut off your engine remotely. Buses are getting the same capability, in case terrorists want to re-enact the movie Speed. The Pentagon wants a kill switch installed on airplanes, and is worried about potential enemies installing kill switches on their own equipment.

Microsoft is doing some of the most creative thinking along these lines, with something it's calling "Digital Manners Policies." According to its patent application, DMP-enabled devices would accept broadcast "orders" limiting capabilities. Cellphones could be remotely set to vibrate mode in restaurants and concert halls, and be turned off on airplanes and in hospitals. Cameras could be prohibited from taking pictures in locker rooms and museums, and recording equipment could be disabled in theaters. Professors finally could prevent students from texting one another during class.

The possibilities are endless, and very dangerous. Making this work involves building a nearly flawless hierarchical system of authority. That's a difficult security problem even in its simplest form. Distributing that system among a variety of different devices -- computers, phones, PDAs, cameras, recorders -- with different firmware and manufacturers, is even more difficult. Not to mention delegating different levels of authority to various agencies, enterprises, industries and individuals, and then enforcing the necessary safeguards.

Once we go down this path -- giving one device authority over other devices -- the security problems start piling up. Who has the authority to limit functionality of my devices, and how do they get that authority? What prevents them from abusing that power? Do I get the ability to override their limitations? In what circumstances, and how? Can they override my override?

How do we prevent this from being abused? Can a burglar, for example, enforce a "no photography" rule and prevent security cameras from working? Can the police enforce the same rule to avoid another Rodney King incident? Do the police get "superuser" devices that cannot be limited, and do they get "supercontroller" devices that can limit anything? How do we ensure that only they get them, and what do we do when the devices inevitably fall into the wrong hands?

It's comparatively easy to make this work in closed specialized systems -- OnStar, airplane avionics, military hardware -- but much more difficult in open-ended systems. If you think Microsoft's vision could possibly be securely designed, all you have to do is look at the dismal effectiveness of the various copy-protection and digital-rights-management systems we've seen over the years. That's a similar capabilities-enforcement mechanism, albeit simpler than these more general systems.

And that's the key to understanding this system. Don't be fooled by the scare stories of wireless devices on airplanes and in hospitals, or visions of a world where no one is yammering loudly on their cellphones in posh restaurants. This is really about media companies wanting to exert their control further over your electronics. They not only want to prevent you from surreptitiously recording movies and concerts, they want your new television to enforce good "manners" on your computer, and not allow it to record any programs. They want your iPod to politely refuse to copy music a computer other than your own. They want to enforce their legislated definition of manners: to control what you do and when you do it, and to charge you repeatedly for the privilege whenever possible.

"Digital Manners Policies" is a marketing term. Let's call this what it really is: Selective Device Jamming. It's not polite, it's dangerous. It won't make anyone more secure -- or more polite.

---

Bruce Schneier is chief security technology officer of BT, and author of Beyond Fear: Thinking Sensibly About Security in an Uncertain World.

Directly connect to your corpnet with IPsec and IPv6

Wed, 25 Jun 2008 16:55:59 +0000

Contrary to popular belief, the rumors of my demise have been greatly exaggerated. Well, ok, no actual rumors, but hey, one can dream, huh? My spring calendar was full of events in Asia and Australia, then TechEd US seemed to suddenly appear out of nowhere! So I've been kinda swamped. I've missed writing here; it's good to get back into the swing.

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.

I spy - employees snooping around?

Mon, 23 Jun 2008 09:28:00 +0000

Apparently many employees ( nearly half ) have the habit of snooping around within the company. This according to a new research study by Cyber-Ark. Many gain access using privileged accounts such as administrator or root passwords, which the research found were not changed that often.

"Cyber-Ark said privileged passwords get changed far less frequently than user passwords, with 30 percent being changed every quarter and 9 percent never changed at all, meaning that IT staff who have left an organization could still gain access."

This is a bit unnerving - most organizations should be following compliance mandates such as SOX to isolate administrator access from content. And using technology to enforce this..

Leveraging Data Leak Prevention Technology to Secure Corporate Assets

Mon, 23 Jun 2008 09:00:00 +0000

(Source: Trend Micro) Protective measures such as VPNs, firewalls, and network monitors provide audit trails and prevent unauthorized external access to information, but they dont address the rising threat of internal users. Learn how an effective DLP solution can help prevent data leaks and meet compliance regulations such as SB-1386, GLBA, EU DPD, Sarbanes-Oxley, and HIPAA requires intelligent content filtering solutions that enforce security policies.