Forwarded from: H C <keydet89at_private> Cc: pattonmeat_private Having been a military officer myself, I would second the below remarks, but with a caveat...anyone who *wants* to learn, can. If someone is interested in learning what's going on and what needs to be done, they will. The only way to get some people interested is to make it part of their evals. When I was in grad school at NPS, a really bright sailor stumbled across the fact that one of the USMC Maj students had his C:\ drive shared out R/W to the world. The sailor approached the Maj on the side, out of the public eye, and mentioned it to him, with information about how to secure the box. The Maj (being field grade) chewed the sailor a new one. > I would second this but having been thru what the USAF purports to > call CompSci training hosted at Biloxi, MS we are evermore doomed to > failure. It is from this pool of 'talent' that the USAF relies upon > to staff Lan shop officers. > Instead of spending tons of money on debatable security measures I > wish the feds would instead put every last sysadmin thru a technical > boot camp. And pound into their thick brains the absolutely > minimally acceptable security/administrative procedures. There need to be far more fundamental changes than that. As long as officers (and anyone else) must compete for promotion, and that process uses entirely separate criteria, the process will not change. As anyone in the military knows, particularly in the officer ranks, many positions are for a year or 2 only. So that means as soon as you get in, you start bucking for that next assignment. > That and send the admins to SANS conferences where they just might > realize the world is a dangerous place and that just because you're > gov't or military doesn't mean your network is invulnerable. I don't think that SANS is a one-size-fits-all solution. I teach an Incident Response Course for NT/2K/XP, and can teach a room of 16-20 people for the cost of sending 3 people to SANS. My point is that the appropriate solution needs to be found for the problem. If the problem is a lack of knowledge on NT/2K security and IR, then going to a conference that is heavy in Linux/Unix won't help. > Whenever I meet a sysadmin (contractor or uniformed) that works for > the gov't I always assume they are incompetent until they prove > otherwise. Interesting approach to the "guilty until proven innocent" rule. > And regrettibly the incompetents far outnumber the clueful. I don't take the same approach as above, but I do find far more incompetents out there than clueful types. I had to respond to an incident once (ended up being sadmin/IIS) and when I asked the certified MCSE+I for the IIS web server logs, he sent me three .evt files. The public lists are populated with people who find something 'suspicious' on an NT machine, port scan it and compare the results to known default trojan port lists. I've developed a hypothesis for this. I, as do many, know that NT/2K systems can be secured to a degree, and that a defense-in-depth approach combined with monitoring is a very good way to go. Yet, far too often, admins through up their hands and say, "Microsoft doesn't provide me with a way to consolidate my EventLogs in one location." When I hear this, I usually find that: a. Auditing isn't even enabled. b. The Resource Kit (w/ the dumpel.exe utility) is on their shelf. c. Win2K comes w/ a utility for turning EventLog entries into SNMP traps (not entirely useful, but it's something). d. They have high-speed Internet access, so they can easily join lists, and research things like syslog, Perl, etc. So...my theory is that it isn't the admins fault at all...it's the managers. Why? B/c managers basically schedule admin's time, right? If a manager says that it's more important that the admin perform helpdesk functions, then the admin does that. However, if a manager were to make an admin responsible for security, and provide him w/ the necessary resources (ie, training, etc) then security might be a priority. Thoughts? - ISN is currently hosted by Attrition.org To unsubscribe email majordomoat_private with 'unsubscribe isn' in the BODY of the mail.
This archive was generated by hypermail 2b30 : Sat Mar 09 2002 - 04:58:54 PST