Re: Oh Dear, Where to start?!

[Jeff <jam () zoidtechnologies com>]

On Wed, Jun 25, 2003 at 04:55:46AM -0700, Steve Frank wrote:
> Hey everyone,
>
> Ok... I am in a bit of a jam here and I was hoping to get some feedback
> from some of you with appropriate experience in the field of network
> security and policy development.

ok.

> I am an senior at RIT studying (essentially) systems administration. My
> main focus and priority has been computer security and policy development.
> I recently took a internship with a small government office helping out
> with computer administration tasks. Upon arrival, I decided it would be
> fun to do a windows update to see what sort of things would come up for my
> PC. Low and behold, there were over 40 critical updates, driver updates,
> and recommended updates.

well, do those updates but make sure you don't introduce new bugs by blindly
installing things. install appropriate updates to *all* workstations and
servers as a matter of policy. search mailing list archives and other
resources specific to that platform for 'problems' that may occur if you
install certain updates.

> Right off the bat this triggered the feeling that there was absolutely no
> security or update plans in place at this particular organization. I
> quickly addressed the issue, and have been working to draft a
> comprehensive security policy and implement technical controls.

good. documentation is the best place to start. suits like that,
particularly government ones. use HTML4 for structure and CSS2 for layout
instead of a proprietary markup format like win32's 'doc'. that way if you
need to publish your policy to the public (which you should do, so can have
multiple eyeballs scrutinizing your policy and helping to tighten it), you
open yourself to a population that uses standards compliant browsers, but
has no way of opening a doc file. security people don't always have win32 on
their desks.

> What I need advice on is the following: If you were introduced to a mixed
> network (literally all versions of windows since 3.1 and mac systems) that
> have no updates, backups, or patches installed... connected to a network
> with only a basic NAT table and no other security... with not even
> anti-virus software enabled... with no user policies or disaster plans in
> place... with unprotected netbios shares everywhere... where would you
> start the process of building some sort of security solution?

first off, upgrade all those 3.1 machines to something *recent* and
*supported* by the vendor. windows 3.1 is *definately* not supported
anymore which is a huge risk.

> I mean, I've seen passwords on monitors, shared accounts, open public
> ports (even the wiring cabinet was unlocked in plain view of passbys to
> the building). I've been tasked with creating the security policies
> relating to internet use, network and phone use, passwords, physical
> security, backup/disaster plans, antivirus, incident response, email
> use/protection, and whatever else needs done. This wouldnt be so bad
> normally I guess, but there is virtually no budget allocated to help for
> this project and I have approximately 3 months to do it. To make matters
> worse, I am also responsible for systems admin, network admin, tech
> support, programming, and whatever other tasks may need to be done in the
> meantime.

you have a big job. I can help with some of this stuff, but I won't do it
*all* for free. that is why the gov't is paying you instead of me :).. maybe
we can work out some kind of trade in lieu of cash, though.

> So basically, if you had to start from nothing, where would you start
> first? What would you consider to be the most important things to be
> implemented? I am literally working from ground zero here... heh!
>
> Thank so much in advance ;-)
>
> Steve Frank

0. deploy stateful firewall software and/or hardware immediately if not
sooner. as a standard policy, deny *everything* and poke holes as
appropriate. this is much easier than managing things the other way. handle
"inbound" and "outbound" traffic seperately, but use the same general policy
of "deny everything, poke holes". remember that the more rules you have, the
slower things will be.

1. make policy regarding password length. start with "at least 6 characters,
including at least one punctuation character" so your users will be less
vulnerable to dictionary password attacks. you must do your research and be
willing to *train users* regarding why you are setting things up this way.
talk about using "pass phrases" instead of just "pass words".

2. expire passwords on a set schedule: every 90 days or so. force your users
to change their password. be willing to explain why this is a good thing for
security. do not allow a user to immediately reuse the same password to get
around the expiration. this is especially true for passwords that are
transmitted in the clear over the internet. even if you use https for
"extranet" access, you should have a reasonable password change policy. keep
yourself to this policy, too. change administrator and root passwords once a
month if you are really paranoid or stick with whatever you decide for user
passwords. practice what you preach regardless. you are not above your users
in this regard.

3. install appropriate access controls on all shares. leave no stone
unturned.

4. outsource where your skillset is lacking. I do Linux sysadmin, network
administration and troubleshooting, programming, and ACID-compliant RDBMS
design and administration for example. I outsource to other people what I
cannot handle myself, and find it beneficial for my clients.

5. good security is composed of as many layers as possible, like an onion.
do not stop at just password protection. 

6. do not make assumptions about what the "typical" user (or attacker) will
try in order to get access to your network. do not assume you will not be
attacked from the inside by a disgruntled employee who just got fired..

6. NAT is fine. it offers some degree of protection of the internal LAN. use
of NAT does not exclude #0, though. you need to carefully configure your
router/firewall to DENY packets on the outside interface destined for an
internal (RFC1918) ip address. also deny packets with a SOURCE ADDRESS from
the blocks in RFC1918 destined for the external interface.

7. install appropriate security patches as noted above on *all* workstations
and servers of the network.

8. turn off unnecessary services on servers. if you don't need it, disable
it. you can always turn it back on later.

9. deploy an MTA such as postfix and configure an RBL to block connection
attempts from *known* open smtp relays. there are several donation-funded
services on the internet you can use that are DNS based, so it is pretty
painless to deal with. above all, do not just block based on IP address
block like certain isps do else you will lose perfectly legitimate email to
the bit bucket. this will help control the deluge of SPAM to your inboxes.

11. deploy LDAP for directory services. it is portable and open (two things you
must have when you are connecting via multiple machines in a hybrid
[unix/mac/win32/printers] environment) and you can find browser based
interfaces for it, for free, quite easily. LDAP can handle things like
username/passwords, email address storage, etc etc. see
http://www.openldap.org/ for additional information.

12. deploy IMAP as part of your mail service instead of POP3. see
http://www.imap.org/ for the reasons why.

13. scrutinize every publically accessable server (especially webservers)
for security issues. remove accounts on the webserver that do not belong,
etc. if you have a DMZ, audit all those machines with *extra* scrutiny. do
not stop at just the webserver.

14. deploy DHCP to manage host configuration issues including ip address,
dns server, etc. this might not be an obvious thing, but think about the
possibility of renumbering your network from your desk instead of walking to
every IP printer on the network and manually changing things. with DHCP you
can lock down what MAC addresses are allowed to get an IP address. that
means that even if an attacker shows up dressed as a tech and plugs their
laptop into your network (or happens upon your wireless network from the
parking lot) they will not be able to get an ip address without spoofing the
MAC address.

15. install appropriate virus management software on the IMAP server that
will scan MIME attachments upon receipt, before the message even reaches an
OE install.

16. *TRAINING OF END USERS*... this should probably be #1 or #0 in the list.
teach users to scrutinze what they are clicking on, including attachments.
if the attachment says "exe" or "bat" or "jsp" or whatever, explain the risk
in blindly clicking on something.  talk about the easy spread of viruses via
ignorance of the technology. ignorance is bad, right?

17. do not be afraid to enforce your security policies. if you catch a user
doing something out of bounds point out the mistake but do not chastise or
attack, as that is not helpful.. instead, explain an appropriate way of
doing things and be willing to offer details regarding your decision. if you
are unsure about something *NEVER* say "I don't know".. look it up. keep
management advised of your enforcement duties and get their full support on
the matter.

18. deploy SSL ("Secure Socket Layer") technology to provide encrypted
access to web services and email boxes from outside the office.

19. auditing. create individual user accounts. do not condone the use of
shared accounts and remove them as quickly as humanly possible. create
users, assign them to appropriate groups, and give the group the permissions
you need. this will make it easier to change permissions on things down the
road instead of having to edit each user by hand.

20. install appropriate virus protection software on workstations. there are
several commercial solutions available with different price ranges. pick
something that will scale to a large number of users easily and one that
offers frequent updates.

21. did I mention auditing yet? :) very useful for being able to track down
problems in an emergency. I can't stress this enough. this includes good
system logs showing login and logout, etc. syslog is your friend. you can
configure syslog to send messages to a remote machine, and do so for the
entire unix network. this is very handy because you can watch some files
from one machine in real time, and if any of the machines is compromised,
the attacker will also have to compromise the syslog machine to scrub your
audit trail.

22. syncronize all workstation and server clocks with NTP. *when* you need
forensics because of a compromise, you will need accurate timestamps
otherwise the information is suspect. set the BIOS clock to use GMT, and
configure the workstations to have the appropriate timezone. setting BIOS
clock to GMT is a pain in win32 (or at least it was the last time I used it,
which was years ago), but is easy and appropriate in other environments such
as unix (mac os x, linux, bsd, AIX, ultrix, etc).

23. you can install a web proxy/cache such as squid but if you are using NAT
anyway you do not *need* it. you can configure squid to require
authentication. if you get rid of NAT and install squid, you can lessen
abuse of bandwidth by employees. it has flexible and powerful logging
options, etc.

24. effective security is layers, like an onion. the more layers you have,
the less likely anyone but the most determined of attackers will be able to
breach your network. it can still happen, but it will be far less likely.
security is a game of managing risk and layers like an onion.

25. strongly discourage your users from writing down passwords. if you
discover a password written down in full view of other humans, expire the
password immediately and report the issue to management, no exceptions. hold
yourself to the same policy.

26. physical security is important too.. lock down cabinets, and make sure a
*small* set of people have access to the keys. if you need to have more than
a couple of employees with physical access to cabinets, keep *extremely
tight control* over the keys, and keep a *detailed* log regarding who
checked out what keys and when. use off-the-shelf card readers to provide
that famous audit trail, instead of "traditional" keys. *every* entry
through one of your locked doors should trigger a log entry someplace so you
know exactly *what* key went through *which* door and *when*. audit trail
audit trail audit trail.

27. download nmap (you know, that tool those hacker people used in "Matrix
Reloaded") and use it from an external host on the internet to scan your
outside facing hosts for issues. see http://www.nmap.org/

28. subscribe to bugtraq and *read the postings*. don't forget the archive!

29. visit http://www.securityfocus.com/ .. they have extensive clue.

30. shut off "convenience" features in OE if you are forced to use that.
things like "automatic opening of attachments" really suck as a default
option. this might have been fixed in recent versions, though, because of
complaints from sysadmins. you will have to reconfigure existing
installations to at least pop up some kind of dialog box that the user has
to accept before an attachment is opened.

31. follow the license for all software you use. get the advice of qualified
counsel if you have questions. absolutely no exceptions.

32. buy support from the vendor or solution providers (like me) for all
platforms you are using.

33. DO NOT CONDONE SOFTWARE PIRACY. IMMEDIATELY REMOVE PIRATED SOFTWARE FROM
THE NETWORK.

34. DO NOT VIOLATE A LICENSE AGREEMENT, even by "accident". you will get
audited eventually and you must have a trail that shows you have proper
licensing for all software in use on your network. you cannot plead
ignorance of the license in court, and the vendor will win (IANAL, see #31)

35. do not use security through obscurity ("they will never find my
network") as your *only* layer of security.. remember the "layers like an
onion" thing.

36. configure all MUA software to send PLAIN TEXT email messages. educate
users regarding the dangers of HTML and other junk in email. DO NOT send
email with HTML unless you know for a fact the recipient doesn't mind. it is
considered rude at the very least. most SPAM comes in the form of an HTML
tag soup, and there are lots of people that delete email with html in it
without prejudice.

37. in a secure environment, open source software is basically a
requirement. open source software is (usually) free except for distribution
expenses like cd-roms and shipping costs. often you can download open source
software via the internet without paying those expenses, thus saving money.
you still need to buy support from outside sources which is how companies
like redhat software, inc. and consultants like me make money.

38. you can't control hardware expenses all that much, but save money on
software where ever you can. spend your public funds wisely young jedi.

39. talk to other professionals that have real life experience in this area.
your post to the mailing list resolves this objective nicely.

40. educate your users (*especially* those that deal with the public, but
insist that management show up to the training sessions too) about "social
engineering" techniques. don't spend millions on a computer network and
neglect the fact that the weakest link in your security is the *humans*
involved, not the computers. look up "kevin mitnick". he has a really good
book specifically about this topic which you should immediately purchase and
read in it's entirety. http://www.defensivethinking.com/aod/index.php

41. read http://www.rsasecurity.com/solutions/idmgt/index.html

42. talk to someone that has a current security clearence with the military.
go over your objectives and ask for advice.

43. disable telnet, rsh, rlogin, rcp, ftp, etc. use software from
http://openssh.com/ instead.

44. make backups of everything to an external media (cdrom, tape, etc) and
store it off site in case of disaster.

45. do not become a BOFH.

46. use CVS for version control of your configuration files. audit trail.

47. talk to your professor(s) regarding additional security measures.
unfortunately the professors I have met have very little real world
experience, so their advise is to be taken with a huge grain of salt. focus
your search on professors that have a unix background. even my obscure
university (emich.edu) has one CS prof that knows unix, and there might be
others.

48. use kerberos version 5 when ssh isn't appropriate.

49. use GNU Privacy Guard (GPG)

please contact me if you have any questions or concerns.

regards,
Jeffrey A. MacDonald
Hacker
-- 
|| Jeff - http://zoidtechnologies.com/

Attachment: _bin
Description: