Problem is, some feces for brains boss is always going to come along and tell you to do what you know is not in the best interest of security. And when the problem rears its ugly head, YOU take the heat, not the idiot who insisted you go against proper procedure.
All I can advise, is document, document, document, then when it does come down, and they point the fickle finger of fate at you, you can always produce the documentation that 'da bozz' made ya do it...
A basic security mindset is a combination of paranoia, a talent for
contingency planning, and an understanding of business need.
My suggestion was to include a couple of courses in the curriculum.
1. Engineering Ethics
How to play fair
Right and wrong, dealing with conflicting responsibilities
2. Engineering Paranoia
The world doesn't play fair
Bad data, safety factors and progressive collapse
I'm not sure you can really teach someone the right combination
of ethics and paranoia to be successfull. I can teach anyone the
technical stuff, or give them a really thick book. But best
practices aren't a substitute for understanding the business and
sound judgement.
The problem is good security people have to cover alot of
ground, and be at least /good/ in all of it. They have to have a
solid understanding of all the systems and networks they are
protecting as well as the customer requirements and business cost/beni
stuff.
One issue I see is a general lack of understanding with
employers as to what is needed. The idea of the paranoid block
everything type that must be restrained seems stuck in many minds.
Unfortunately, this leads to issues, total ICMP blocks, bad ECN
handling, etc. As well as very little drive for people to learn what
they need.
I think it comes down to being able to deal creatively with a
lack of total control, and find ways to limit what you cannot
eliminate.
If the balance cannot be found, you end up with security
problems, or performance issues, pissed customers and broken networks.
Security specialists can't be everywhere, can't do everything, and
can't stop every bad thing. The reality is the people who have
the biggest impact on security don't have security in their job
title. Instead of a neighborhood watch do we need a network watch?
While we need a few people with "deep" security knowledge, we also
need to spread a thin layer of security pixie dust throughout the
entire organization.
Is it really a lack of control. While some security specilists
carry a big stick, on most projects security is just one of
many specialities required to work together. If you are a
security specialist, just getting invited to a project before
its finished is a major accomplishment.
:Instead of a neighborhood watch do we need a network watch?
:While we need a few people with "deep" security knowledge, we also
:need to spread a thin layer of security pixie dust throughout the
:entire organization.
The NIPC, CERT, OCIPEP(Canada) and other organizations try to
fill this role. The Incidents mailing list also
tries to do this on a more ad hoc basis, along with the honeynet
projects, and to a great extent Nanog. If ones definition of security
includes integrity and reliability, then Nanog has been performing
that role since its creation.
The problem that exists with the neighbourhood watch model is that
it assumes some sort of community and, despite a few exceptions,
there is no community of internet providers.
There are communities of network engineers and other specialists, but
the possibility of corporations getting together with a common goal,
which may temporarily supercede their individual competetive advantage,
is just not going to happen. They can have industry associations, lobby
groups, interest groups, and other representative bodies, but community
is not one of these, and thus any network watch program which depends
on community will be hampered.
So, the challenge is to find a model of information sharing in which a
balance between effectiveness and the protection of competitive information
that is slanted heavilty to the latter. This on top of providing value
to the participants.
There are some private security alert services like this. I can personally
highly recommend the securityfocus ARIS tool and their commercial Threat
Management System. NAI's virus alert system is excellent, as is
a similar service from sophos.com.
The non-classified government briefings I have seen don't really provide
value from an up to the minute threat analysis perspective. They might
help an executive hold an intelligent conversation on current affairs,
but they do little for people who are responsible for protecting the
infrastructure.
Personally, I would like to see a mixture of the MAPS RBL and
aris.securityfocus.com available, where emerging hostile netblocks
can be blackholed for short periods of time using attack information
gathered from and coroborated by a vast array of diverse sources.
It strikes me that much of the focus seems to be people on one hand
wanting "deep security expertise", which is considered technical, and on
another finding it difficult to actually have that single person be able
to impact enterprise/network-wide security. Since "deep security"
experts are a valuable commodity, it is unlikely that spreading them
throughout an organization is feasible.
What needs to change in this model is how one defines a "security
expert". While some deep technical knowledge in security technologies
relevant to your environment is critical, that person should hardly be a
bottleneck for the security organization. In fact, that person should
rarely--if ever--communicate outside his/her organization. What is
needed is a someone capable of "creating" the pixie dust you spoke of,
Sean. That dust has to be sprinkled, it's hard work, and a technical
professional cannot do it. The problem is that when an organization
sees a need to focus on security, the first thought tends to be to get
an "expert" hired on. In reality, this expert will have little effect
since he/she will not be able to stick a finger in every piece of pie
around. Instead, getting the HR department to focus on a "strategic"
security manager should be the first task on the security checklist.
This person need not be a deep technical expert, though some level of
technical expertise is usually desirable. Higher on the list is
communication skills, management by influence (as opposed to authority),
educational experience or talent, and a deep understanding of how to
promote security awareness throughout an organization.
Surprisingly, these people are both easier to work with and easier for
HR to target than your average "deep security expert". If the goal is
to establish security as a priority for an organization, and ultimately
have far greater impact than a couple of security engineers, this is the
type to be looking for. They don't need to have 20 years of security
experience. People with *some* security experience and a whole boatload
of business, education, management, and political experience fit this
bill. The profile of this person usually lines up with what would be
termed a CIO.
Once this person is in place, it becomes a lot easier to coordinate
security both within and outside of an organization. The "community"
model for incident response has been shown inadequate by most
institutions which value their privacy. I would think the ISP/network
provider companies would be less sensitive to this, and look for
meaningful ways to cooperate. Having a person where responsibility for
this sort of thing would rest in each of the companies would go a long
way to getting it started. "Deep security experts" are definitely not
suited for this type of work.
Just my $.02
Cheers,
Ben
Have a look at SAFE (url in sig).
We detect smurf amplifiers and I'm currently looking at ways to export
data to companies regarding large smurf amplifiers (>x250 amplification)
who refuse to close after X number of warnings.
I expect it will run on a free, but subscribed + authenticated basis (ie,
a company subscribes and gives the IP's of their DNs servers and those
servers are authorized to do lookups, but script kiddies cannot).
Many a year ago I ran a "scan and bitch" service for smurf amps (afaik it
was the first, predated netscan.org and powertech.no). Measuring raw
packet multiplications is really a terribly incorrect method to measure
the "badness" of a smurf amplifier. People routinely have T1's replying
50,000 times, and other such junk. You might be better off going back
through all the broadcasts you got positive hits from, and try sending
bigger packets and measuring actual received bandwidth. You'll find that
multiplication has almost no bearing in predicting the bandwidth of an
attack.
As for your service listing them... Smurfs aren't spam, so I'm not sure
what you plan to accomplish by making the data available via DNS, it would
really only be useful as a BGP feed. Even then, it's usefulness is
limited. I suppose you could null route traffic to specific broadcast
addresses to prevent people originating smurfs from your network with
minimal impact on legit services, or if you are a big transit provider
with balls you could apply it to all your customers.
There is no protocol (disclaimer: that I'm aware of) for distributing IP
lists that could be filtered by source address, let alone other more
intelligent things like distributing firewall rulesets so you could pick
off only the echo replies, BUT MAYBE THERE SHOULD BE. <-- HINT!
:Have a look at SAFE (url in sig).
:We detect smurf amplifiers and I'm currently looking at ways to export
:data to companies regarding large smurf amplifiers (>x250 amplification)
:who refuse to close after X number of warnings.
Yeah, that uses a bit more of the anti-spam model than a network
protection model. Aris takes IDS logs from subscriber sites,
normalizes them and generates stats (among other things). After
the data is normalized, they show emerging trends and anomalies.
An example of this would be if an attacker started scanning across
the Internet for ssh servers, this could trigger IDS's at multiple
sites, which would increase the profile of attackers ip addr.
What I was suggesting is that this data be cleaned and a list of
actively hostile hosts be distributed to subscribers for temporary
blockage, either by port filter, or blackholed by prefix on a reasonably
real-time basis.
As for your service listing them... Smurfs aren't spam, so I'm not sure
what you plan to accomplish by making the data available via DNS, it would
really only be useful as a BGP feed. Even then, it's usefulness is
limited. I suppose you could null route traffic to specific broadcast
addresses to prevent people originating smurfs from your network with
minimal impact on legit services, or if you are a big transit provider
with balls you could apply it to all your customers.
SAFE is a daughter-project of the IRCNetOps project (www.ircnetops.org)
who areIRC network admins from small and large networks who came together
last year after getting rather pissed off by constant DoS attacks.
No, not just little admins with shells on little networks, but also bigger
admins on the bigger networks who run servers at ISP's too.
The service could be used to deny IRC access to their networks to people
who come from broken networks.
There is no protocol (disclaimer: that I'm aware of) for distributing IP
lists that could be filtered by source address, let alone other more
intelligent things like distributing firewall rulesets so you could pick
off only the echo replies, BUT MAYBE THERE SHOULD BE. <-- HINT!
Maybe there should be 
Wnat to do it? 