Saturday, July 19, 2008

Spliced feed for Security Bloggers Network

Spliced feed for Security Bloggers Network

The Last HOPE, day 1 [Kees Leune]

Posted: 18 Jul 2008 07:49 PM CDT

Today was the first day of the Last HOPE convention. Being married with children, I no longer spend full days at events like this, but the time I was there was well spent. Not only did I get to meet some people face to face, I also attended some talks.

More specifically, I went to the first talk on botnet research, the death star risk modeling talk/earth intelligence network and to the talk on the Attendee Metadata project. After that, I took a small break, before sitting in on Myrcurial's talk about climbing the corporate ladder. Then I browsed the projects area, picked up a lock picking set at the Toool table and spoke with some other person who I wanted to meet up with.

Botnet research, Mitigation and the Law
The talk on botnet research was interesting in that it presented a perspective on cases that many of the attendees never had. I found the references to Operation Botnet interesting because I had just heard the other side of that same story. The discussion of all the possibly applicable laws and regulations was thorough, but not new to me. For most of the people in the room, it was a very good introduction.

Death Star Risk Modeling
Death Star Risk Modeling was a CISSP 101 introduction to risk modeling. Interestingly explained, and nicely illustrated with Star Wars analogies. The observation that I took home from this was "If it is worth putting up, it is worth protecting".

Earth Intelligence Network: World Brain as Earth Game
Freaky.

The Attendee Meta-Data Project
Poorly prepared and presented even worse. The idea is very interesting, but the implementation sucked. These guys were very lucky that they are no students of mine.

From a Black Hat to a Black Suit
Highly entertaining and informative and for me definitely the best talk of the day. A number of good lessons for those of us who are planning to make their carreer in corporate information security and who are not afraid of the word "Suit".

Who’s at HOPE? [tssci security]

Posted: 18 Jul 2008 06:27 PM CDT

Anyone here want to meet up? Message me.

LinkedIn to VoIPSA [Voice of VOIPSA]

Posted: 18 Jul 2008 01:27 PM CDT

I would like to invite any VoIPSA LinkedIn users to join the new LinkedIn VoIPSA group.  While we already have documentation on the website regarding the Board of Directors and the Technical Board of Advisers, there wasn’t really much in the way of identifying and networking with other members of our organization who are not on either of these boards, other than of course the VoIPSec mailing list (which doesn’t have a public membership roster), so I’ve established this group to fill that void.

Facebook is creepy, according to Wired [Roer.Com Information Security - Your source of Information Security]

Posted: 18 Jul 2008 01:00 PM CDT

According to Simon Dumenco over at Wired, Facebook is too creepy to offer business value. I certainly agree that there are aspects of Facebook that might be creepy, but I do not think that alone is the main reason to not use Facebook in a business environment.

A couple of his comments are good, though:

"The ease with which Facebook can be used to broadcast your whereabouts adds a particularly disturbing dimension for executives who would surround themselves with security in real life but are lulled into complacency by Facebook's tidy veneer. Last year, the British military sent a directive to its army units to avoid revealing their service connections online—"Be particularly careful if you are on Facebook, MySpace, or Friends Reunited"—fearing that, yes, Al Qaeda could use them to track prey. Your business competitors might not be terrorists per se, but Facebook can be useful for anyone trying to poach your M.V.P.'s."

I think this point is valuable to Twitter, Plaxo and LinkedIn too - they all love the Status update these days.

Another point, made by David Weinberger is particularly interesting:

"Younger people violate older people's idea of proper behavior when it comes to privacy,"

Now, is this a challenge for the younger people, or for the older ones? Who needs to adopt? The Young? The Old? The Wise? Or heaven forbid - me?

----

More on Facebook:

 

Move to New Zealand, Get Out Of Jail Free [securosis.com]

Posted: 18 Jul 2008 12:20 PM CDT

New Zealand is absolutely my favorite place on the face of the planet. I’ve made it down there twice, once for a month before I met my wife, and once for just under 3 weeks with her as we drove thousands of kilometers exploring as much of both islands as we could. As much as I love it, I don’t think I’d want to live there full time (I kind of like the US, despite our current administration).

But the latest news from New Zealand does give me a bit of an itch to head back down and “experiment” with the law. Seems a young fellow made about $31K giving some bad guys software they used to rake in something like $20M. Bad stuff-

Mr Walker was detained in the North Island city of Hamilton last November as part of an investigation with US and Dutch police into global networks of hijacked PCs, known as botnets

He’s 18, so odds are jail time, right? Like serious jail time?

Nope.

Judge Judith Potter dismissed the charges, relating to a 2006 attack on a computer system at a US university, saying a conviction could jeopardise a potentially bright career.

Nice. Hey, I think I might want to be a security guard at a convenience store, okay if we drop that little assault and robbery thing? I made way less than $31K? Heck, I didn’t steal the cash, I just drove the car, gave someone the gun and ski mask, and…

Zodiac - DNS Protocol Monitoring and Spoofing Tool [Darknet - The Darkside]

Posted: 18 Jul 2008 02:29 AM CDT

Zodiac is a DNS protocol analyzation and exploitation program. It is a robust tool to explore the DNS protocol. Internally it contains advanced DNS routines for DNS packet construction and disassembling and is the optimal tool if you just want to try something out without undergoing the hassle to rewrite DNS packet routines or packet...

Read the full post at darknet.org.uk

Thanks to the EUCI! [Branden Williams' Security Convergence Blog]

Posted: 17 Jul 2008 08:42 PM CDT

Thanks to everyone at EUCI and their great hospitality in Vail. I'm looking forward to working with some of you soon!

The Last HOPE device preparations [Kees Leune]

Posted: 17 Jul 2008 08:02 PM CDT

While preparing to head down to The Last Hope, I figured that I'd lock down my N800 a bit more than I usually do. The network environment might be "somewhat" hostile, and I prefer to expose my device as little as I can.

The N800 has a terminal application, but it is inadequate for serious work. I started by installing the openssh package from the maemo repository, but I also realize that this means that I get an openssh server running on the device. Have to remember to shut that off when I'm done ;)

After booting, the N800 has an impressive array of ports listening on the network:

Nokia-N800-51-3:~# lsof -i
COMMAND    PID   USER   FD   TYPE DEVICE SIZE NODE NAME
sshd       742   root    3u  IPv4   2608       TCP *:ssh (LISTEN)
dnsmasq   1041 nobody    4u  IPv4   4328       TCP Nokia-N800-51-3:domain (LISTEN)
dnsmasq   1041 nobody    5u  IPv4   4329       UDP Nokia-N800-51-3:domain
dnsmasq   1041 nobody    8u  IPv4   5637       UDP *:49156
sshd      1273   root    3r  IPv4   5545       TCP 10.16.1.100:ssh->10.16.1.101:1542 (ESTABLISHED)
telepathy 1292   user    4u  IPv4   6459       UDP 10.16.1.100:49157
telepathy 1292   user    5u  IPv4   6460       TCP 10.16.1.100:49157 (LISTEN)
telepathy 1292   user    6u  IPv4   6461       UDP Nokia-N800-51-3:49157
telepathy 1292   user    7u  IPv4   6462       TCP Nokia-N800-51-3:49157 (LISTEN)
telepathy 1292   user    8u  IPv4   6465       UDP Nokia-N800-51-3:49158->Nokia-N800-51-3:domain
telepathy 1292   user   10u  IPv4   6468       UDP Nokia-N800-51-3:49159->Nokia-N800-51-3:domain

That's obviously too much. Let's start by disabling telepathy. Telepathy is the N800's messaging application, and I usually have a SIP account set up. Disabling that account  immediately removed all instances of the program and also closed all ports it had open.

I do not worry too much about sshd, since I will remove the ssh-server package when I'm done cleaning up. That leaves the dnsmasq package, which is needed to resolve host names.

To fix the dnsmasq ports, all you have to do is edit /etc/dnsmasq.conf and uncomment the line with the phrase 'bind-interfaces'. Switch to offline mode and then reconnect to the wireless network, and you should be all set:

Nokia-N800-51-3:~# lsof -ni
COMMAND  PID   USER   FD   TYPE DEVICE SIZE NODE NAME
sshd     743   root    3u  IPv4   2623       TCP *:ssh (LISTEN)
dnsmasq 1042 nobody    4u  IPv4   4345       TCP 127.0.0.1:domain (LISTEN)
dnsmasq 1042 nobody    5u  IPv4   4346       UDP 127.0.0.1:domain
sshd    1293   root    3r  IPv4   6037       TCP 10.16.1.100:ssh->10.16.1.101:1631 (ESTABLISHED)

In an environment like The Last HOPE, you really really want to only do stuff when you are VPN'ed into a secure network. I connect to my VPN gateway by IP (just in case someone is doing some poisoning). The maemo vpnc-gui package will allow you to do just that.

As a result, this will leave me with 0 ports open that are exposed to the other Last HOPE contestants and I feel a little safer bringing my tablet ;)

Do not forget to turn off ssh by removing the package (safest) or by removing the ssh package from your boot sequence. Please do not forget to make sure to have a root backdoor if you chose the latter option.

Password Really is the Key to the City [CultSEC Blog]

Posted: 17 Jul 2008 06:05 PM CDT

I haven't posted in a couple of weeks. But this little incident was enough to jump in the saddle real quick. I am working on a couple of other posts which will appear soon.

This incident ongoing in San Francisco is an excellent example for employing "checks and balances." There should never be a situation where one person holds the only set of keys to the data. Never. What should happen then?

Well, every company is going to have one or two "trusted" people. I may be going out on a limb here. At least the owner or executive in charge should fit that category. At any rate, the "trusted" person should set an enterprise level password. Then they should write down the password, seal it in an envelope and stash it in a safe deposit box. Wait, you're not done. The enterprise level account should then be used to create sub-accounts for those entrusted to do system admin work. That way, if one of them does something they shouldn't, like locking out everyone's access, the enterprise level admin can still get in.

Of course, there is no real 100% solution to ensuring this type of event doesn't happen. Heck, the executive in charge could decide they've had enough and lock down the systems. Somewhere along the line a human being has to be trusted to do the right thing.

Maybe then, they could have the real keys to the city.

Firefox 3.0 Vulnerability Patched [DVLabs: Blogs]

Posted: 17 Jul 2008 04:18 PM CDT

Posted by Zero Day Initiative
In less than a month after its official release, Mozilla fixed the vulnerability we reported to them in Firefox 3.0.  This vulnerability was acquired through our Zero Day Initiative and reported responsibly to Mozilla on June 17th, 2008.  Mozilla was able to fix this issue in a timely manner, and we look forward to working with them in the future. 

Read all the vulnerability details in our Zero Day Initiative advisory here.


Best Practices for Endpoint DLP: Part 5, Deployment [securosis.com]

Posted: 17 Jul 2008 12:34 PM CDT

In our last post we talked about prepping for deployment- setting expectations, prioritizing, integrating with the infrastructure, and defining workflow. Now it’s time to get out of the lab and get our hands dirty.

Today we’re going to move beyond planning into deployment.

  1. Integrate with your infrastructure: Endpoint DLP tools require integration with a few different infrastructure elements. First, if you are using a full DLP suite, figure out if you need to perform any extra integration before moving to endpoint deployments. Some suites OEM the endpoint agent and you may need some additional components to get up and running. In other cases, you’ll need to plan capacity and possibly deploy additional servers to handle the endpoint load. Next, integrate with your directory infrastructure if you haven’t already. Determine if you need any additional information to tie users to devices (in most cases, this is built into the tool and its directory integration components).
  2. Integrate on the endpoint: In your preparatory steps you should have performed testing to be comfortable that the agent is compatible with your standard images and other workstation configurations. Now you need to add the agent to the production images and prepare deployment packages. Don’t forget to configure the agent before deployment, especially the home server location and how much space and resources to use on the endpoint. Depending on your tool, this may be managed after initial deployment by your management server.
  3. Deploy agents to initial workgroups: You’ll want to start with a limited deployment before rolling out to the larger enterprise. Pick a workgroup where you can test your initial policies.
  4. Build initial policies: For your first deployment, you should start with a small subset of policies, or even a single policy, in alert or content classification/discovery mode (where the tool reports on sensitive data, but doesn’t generate policy violations).
  5. Baseline, then expand deployment: Deploy your initial policies to the starting workgroup. Try to roll the policies out one monitoring/enforcement mode at a time, e.g., start with endpoint discovery, then move to USB blocking, then add network alerting, then blocking, and so on. Once you have a good feel for the effectiveness of the policies, performance, and enterprise integration, you can expand into a wider deployment, covering more of the enterprise. After the first few you’ll have a good understanding of how quickly, and how widely, you can roll out new policies.
  6. Tune policies: Even stable policies may require tuning over time. In some cases it’s to improve effectiveness, in others to reduce false positives, and in still other cases to adapt to evolving business needs. You’ll want to initially tune policies during baselining, but continue to tune them as the deployment expands. Most DLP clients report that they don’t spend much time tuning policies after baselining, but it’s always a good idea to keep your policies current with enterprise needs.
  7. Add enforcement/protection: By this point you should understand the effectiveness of your policies, and have educated users where you’ve found policy violations. You can now start switching to enforcement or protective actions, such as blocking, network filtering, or encryption of files. It’s important to notify users of enforcement actions as they occur, otherwise you might frustrate them unnecessarily. If you’re making a major change to established business process, consider scaling out enforcement options on a business unit by business unit basis (e.g., restricting access to a common content type to meet a new compliance need).

Deploying endpoint DLP isn’t really very difficult; the most common mistake enterprises make is deploying agents and policies too widely, too quickly. When you combine a new endpoint agent with intrusive enforcement actions that interfere (positively or negatively) with people’s work habits, you risk grumpy employees and political backlash. Most organizations find that a staged rollout of agents, followed by first deploying monitoring policies before moving into enforcement, then a staged rollout of policies, is the most effective approach.

Asking The Cisco Systems’ IPICS Expert: Questions 1-5 [Voice of VOIPSA]

Posted: 17 Jul 2008 12:22 PM CDT

Over the past couple of years I’ve been keeping my eye on some of the several vendors’ solutions and emerging systems providing interoperability between disparate radios (800mhz, P25, push-to-talk, VHF, UHF, VoIP, cellular, etc.). Some of these solutions come as single device “magic boxes” like the JPS Raytheon ACU-1000, ACU-2000, ACU-M and ACU-T while others provide more IP-based solutions, such as Cisco Systems’ IPICS (IP Interoperability and Collaboration System).

ipics

As I’ve been working for some time on a whitepaper and presentation entitled “Emergency Communications Infrastructure: Asking The Difficult And Dangerous Questions” — I figured that the time has come to directly ask vendors some of the many questions I have as I’ve read through product literature, release notes, independent evaluations, journal coverage, and the like….even a little IPICS YouTube action.

So, I was very surprised when the email I sent to ipicsasktheexpert@cisco.com bounced (screenshot here!) Rather than go through the various emails and personnel to actually get a response or email address that worked for contacting the Cisco IPICS Expert, I figured I would provide the IPICS Expert the opportunity and privilege to answer my questions in a public forum such as VOIPSA’s Blog, as well as let the community know when they fixed their email address. As the IPICS is a solution, I have focused first on the “heart” — the IPICS Server, described by Cisco Systems as:

A security-enhanced, Linux-based platform that provides an administration console and resource management and hosts the optional Cisco IPICS Policy Engine and Operational Views applications.

Below are the questions. Cisco Systems’ IPICS Expert may either answer the questions in this post’s comments sections or email me the answers. If people in the community have IPICS solution questions, please add them to the comments or email them to me and we’ll get the questions posted on the VOIPSA Blog in the next batch, or the one after, or the one after….you get the idea.

Question 1: The IPICS Server is described by Cisco Systems as "Security Enhanced" — please provide a formal, technical definition for this term.

Cisco Answer

Question 2: On each network interface, by default what TCP ports are open across the 1-65535 range?

Cisco Answer

Question 3: On each network interface, by default what UDP ports are open across the 1-65535 range?

Cisco Answer

Question 4: On IPICS Server 2.1(1), what type and version Web server is running?

Cisco Answer

Question 5: Has this IPICS Server 2.1(1) Web Server version or type changed from previous versions of IPICS Server software?

Cisco Answer

Thank you and I, as well as others I’m sure, look forward to your answers.

Shawn Merdinger

Putting the fun back in threat modeling [Emergent Chaos]

Posted: 17 Jul 2008 11:52 AM CDT

I have an article in the latest MSDN magazine, "Reinvigorate your threat modeling process:"
My colleague Ellen likes to say that everyone threat models all the time. We all threat model airport security. We all threat model our homes. We think about threats against our assets: our families, our jewelry, and our sentimental and irreplaceable photographs (well, those of us old enough to have photos that never existed in digital form do). We model threats based on architecture: there's a wall here, a picture window there, and an easily climbed tree that we can use when we forget our keys. And we model threats based on attackers. We worry about burglars and kids falling into pools. We also worry about the weather, be it earthquakes, snow, or tornadoes.

If I wanted to sound like a management consultant, I'd say you employ a mature, multi-dimensional assessment process, with a heavy reliance on heuristics and low reproducibility across instances. At the same time, it's likely you won't have thought of everything or implemented defenses against every possible attack. It's very unlikely you have a home defense management plan or have ever run a penetration test against your home.

There's a lot in there talking about how and why some threat modeling methods became "heavy" and what to do about it. Underlying that is the start of a way of thinking about threat modeling as a family of related activities, and some ways of breaking that down. In particular, there's a breakdown into asset-centric, architecture-centric, and attacker-centric threat modeling, which I think is a useful step forward.

What works for you in threat modeling? What hasn't worked that you needed to replace?

Good Times in Toronto [Trey Ford - Security Spin Control]

Posted: 17 Jul 2008 08:38 AM CDT

Back in Chicago O’Hare international airport (ORD) for the third time in four days.  I am headed home from a trip to Cincinnati and Toronto for meetings and a presentation at the Toronto OWASP chapter- what a fantastic group!  Special thanks to Nish and Reza for having us out! After a talk on Business Logic flaws, [...]

Facebook Bug Leaks Birthday Data [Darknet - The Darkside]

Posted: 17 Jul 2008 06:10 AM CDT

It’s not a big deal but it does show a problem with the way Facebook deals with data and how much power they have over people’s privacy. A small slip in coding could cause much worse problems that this, plus this could have happened before but no one picked up on it. It takes a certain [...]SHARETHIS.addEntry({ title: "Facebook Bug...

Read the full post at darknet.org.uk

The Last HOPE 2008 [Kees Leune]

Posted: 16 Jul 2008 07:15 PM CDT

While getting ready for the Last HOPE this weekend in New York City, I went through the program. For the time being, my schedule will look like this:

Friday

1100 - 1200 Death Star Threat Modeling (Kevin Williams in Engressia)
1200 - 1300 Citizen Engineer - Consumer Electronics Hacking and Open Source Hardware (Phillip Torrone, Limor Fried in Hopper)
1300 - 1400 From a Black Hat to a Black Suit  - How to Climb the Corporate Security Ladder Without Losing Your Soul (Myrcurial in Turing)
1400 - 1500
1500 - 1600 Introduction to the Open Web Application Security Project (Tom Brennan in Engressia)

Saturday

1000 - 1100 Policy Hacking: Taking Back Public Sector IT (Arjen Kamphuis in Turing)
1100 - 1200 "Off the Grid" Voice/Data Communications (Skip Arey, bernieS in Hopper)
1200 - 1300
1300 - 1400 Keynote address (Steven Levy in Hopper)
1400 - 1500
1500 - 1600
1600 - 1700 Port Knocking and Single Packet Authorization: Practical Deployments (Michael Rash in Engressia)

Sunday

1200 - 1300 What and Who is "Anonymous"? (Alex (DeMiNe0), Dusk, Little Sister, Mike (Sethdood), PokeAnon, Atkins, Ryan "Dr3k" Hannigan  in Turing)
1300 - 1400
1400 - 1500 Featured Speaker (Adam Savage in Hopper)
1500 - 1600
1600 - 1700 Featured Speaker (Jello Biafra in Hopper)
1700 - 1800 No-Tech Hacking (Johnny Long in Turing)

Don't forget that amateur radio operators will meet at calling frequency 147.525 MHz simplex. A special event station W2H will be operating too, so I might hang out with them when I haven't decided yet

Upcoming Webcast- DLP and DAM Together [securosis.com]

Posted: 16 Jul 2008 05:49 PM CDT

On July 29th I’ll be giving a webcast entitled Using Data Leakage Prevention and Database Activity Monitoring for Data Protection. It’s a mix of my content on DLP, DAM and Information Centric security, designed to show you how to piece these technologies together.

It’s sponsored by Tizor, and you can register here (the content, as always, is my independent stuff). Here’s the description:

When it comes to data security, few things are certain, but there is one thing that very few security experts will dispute. Enterprises need a new way of thinking about data security, because traditional data security methods are just not working.

Data Leakage Prevention (DLP) and Database Activity Monitoring (DAM) are two fundamental components of the new security landscape. Predicated on the need to "know" what is actually happening with sensitive data, DLP and DAM address pressing security issues. But despite the value that these two technologies offer, there is a great deal of confusion about what these technologies actually do and how they should be implemented.

At this webinar, Rich Mogull, one of today's most well respected security experts, will clear up the confusion about DLP and DAM.

Rich will discuss:

* The business problems created by a lack of data centric security

* How these problems relate to today's threats and technologies

* What DLP and DAM do and how they fit into the enterprise security environment

* Best practices for creating a data centric security model for your organization

- Rich

Voice of VOIPSA upgraded to WordPress 2.6… [Voice of VOIPSA]

Posted: 16 Jul 2008 03:09 PM CDT

Not wanting to get into any of the problems we had previously, I’ve gone and upgraded this site to be running the newly-released WordPress 2.6. If you see anything strange going on with the site, please do let me know. Thanks.

Are you in Vail for the EUCI Conference? [Branden Williams' Security Convergence Blog]

Posted: 16 Jul 2008 01:18 PM CDT

If so, drop me a line! I'm leaving the home base here in a few hours to head there for the conference. I will be discussing personally identifiable information and why it is important to secure.

After I speak, I'll be high-tailing it to Denver International to catch a return flight home. Hope to see you there!

Stolen Data Cheaper [securosis.com]

Posted: 16 Jul 2008 01:10 PM CDT

It’s rare I laugh out loud when reading the paper, but I did on this story. It is a great angle on a moribund topic, saying that there is such a glut of stolen finance and credit data for sale that it is driving prices down.

LONDON (Reuters) - Prices charged by cybercriminals selling hacked bank and credit card details have fallen sharply as the volume of data on offer has soared, forcing them to look elsewhere to boost profit margins, a new report says.

The thieves are true capitalists, and now they are experiencing one of the downsides of their success. What do you know, “supply and demand” works. And what exactly are they going to do to boost profit margins? Sell extended warranties? Maybe it is just the latent marketeer in me coming to the fore, but could you just imagine if hackers made television commericals to sell their wares? Cal Hackington? Crazy Eddie’s Datamart?

It’s time to short your investments in Cybercriminals, Inc.

-Adrian

Writing a book: The Proposal [Emergent Chaos]

Posted: 16 Jul 2008 12:45 PM CDT

To start from the obvious, book publishers are companies, hoping to make money from the books they publish. If you'd like your book to be on this illustrious list, you need an idea for a book that will sell. This post isn't about how to come up with the idea, it's about how to sell it.

In a mature market, like the book market, you need some way to convince the publisher that thousands of people will buy your book. Some common ways to do this are to be the first or most comprehensive book on some new technology. You can be the easiest to understand. You can try to become the standard textbook. The big problem with our first proposal was that we wanted to write a book on how managers should make security decisions.

That book didn't get sold. We might rail against the injustice, or we might accept that publishers know their business better than we do. Problems with the idea include that there aren't a whole lot of people who manage security, and managers don't read a lot of books. (Or so we were told by several publishers.) We didn't identify a large enough market.

So a proposal for a new book has to do two main things: first identify a market niche that your idea will sell, and second, convince the publisher that you can write. You do that with an outline and a sample chapter. Those are the core bits of a proposal. There are other things, and most publishers have web sites like Addison Wesley's Write for us or Writing For O'Reilly. Think of each of these as a reason for some mean editor who doesn't understand you to disqualify your book, and make sure you don't give them that reason.

With our first proposal, we gave them that reason. Fortunately, both Jessica Goldstein (Addison Wesley) and Carol Long (Wiley) gave us really clear reasons for not wanting our book. We listened, and put some lipstick on our pig of a proposal.

Funny thing is, that lipstick changed our thinking about the book and how we wrote it. For the better.

NorSec - Linkedin group for Nordic Security Professionals [Roer.Com Information Security - Your source of Information Security]

Posted: 16 Jul 2008 11:56 AM CDT

I have created a LinkedIn group called NorSec. The group targets security professionals in the Nordic, with particular focus on Norway.

The group is not publicly available. To be accepted you will comply with the following:

  • Located in Norway (or the Nordics)
  • Currently working within the security industry

The benefits of joining the group are:

  • Join and meet other security professionals
  • Develop a forum for discussions
  • Find job opportunities
  • Find candidates
  • Get answers

Please note - if you are not located in the area, or not in the security industry, you will not be accepted as a member of this group. There are other groups available for you!

To apply: http://www.linkedin.com/e/gis/111057/40E1791B6B9D

You may consider letting me know about your request using the contact form or my e-mail.

Stiennon's Right, Shimel's Wrong - NAC Sucks [CTO Chronicles]

Posted: 16 Jul 2008 11:00 AM CDT

A couple of months ago, Richard Stiennon (of 'IDS is Dead' fame) had a blog article up at Network World, making the argument that "Network Admission Control" is "added complexity and cost that reduces network access while doing nothing for enhanced security."  This drew a predictable response from the likes of Alan Shimel over at StillSecure.  At the time, at least for me, it was just another blog fight and didn't seem that interesting.

This came up again recently though, with the news of a live debate between Stiennon and Joel Snyder.  Shimel's apparently still annoyed and had this prediction on the outcome of the debate.  In re-reading all of the arguments as part of this latest blog-fight, something ocurred to me that changed my initial view of things.

I'm come to the conclusion that Alan is wrong and Richard is right.  Let's look first at the three things that Stiennon cites as how NAC is off-base:

1. NAC does nothing to stop the malicious user with a clean computer from having their way with your network.

2. A zero-day infection will infect properly configured machines with up-todate signatures.

3. NAC violates Stiennon's first and only rule of network security "Thou shall not trust an end point to report its own state." Just as IP address and MAC addresses are spoofed regularly by hackers, machine state can be spoofed.

All three of these reasons are perfectly valid reasons not to like whatever you've been sold.  To be fair, the bulk of Shimel's retorts over this have been to point out that Stiennon's view of the NAC space is behind what current NAC vendors offer to the market.  What occurs to me, though, is that there really is only one vendor that fits Stiennon's description of what NAC is.  A really, really big one.  Whose name begins with C.  The rest of the NAC space moved on a long time ago.

So, on further reflection, I agree with Stiennon.  IDS is dead and Cisco's NAC Appliance sucks.  It's too bad that Cisco's NAC is all Stiennon knows about NAC.

San Francisco Needs A Really Good Pen Tester [securosis.com]

Posted: 16 Jul 2008 09:36 AM CDT

Direct from the “you can’t make this up” department, this news started floating around a couple days ago:

JULY 15, 2008 | 11:55 AM — Right now, San Francisco computer experts are frantically trying to crack an exclusive administrative password of one of their former computer engineers who's sitting in jail for basically holding the city's new multimillion-dollar network hostage.

Terry Childs, 43, is cooling his heels in the slammer on charges of computer tampering for configuring sole admin control of the city's new FiberWAN network so that no other IT officials can have administrative rights to the network, which contains email, payroll, law enforcement, and inmate booking files’ apps and data, according to a published report.

Childs apparently gave some passwords to police that didn't work, and refused to give up his magic credentials when they threatened to arrest him. Seems he set up the password lockout to ensure he didn't get fired after he was cited for poor performance on the job.

There really isn’t much to say, but if you are a kick ass pen tester in the Bay area (perhaps someone booked for a lewd offense you wouldn’t like to see plastered on the Internet) I suspect there’s a potential gig out there for you.

-Rich

No comments: