Dale has apparently been following some of the other traffic. He has his post up on scanning.
He has been hot on this for a while and has been working with Tenable on a series of plugins.
I am a bit more conservative but the white paper is pretty good.
I would work with the engineers to check against test systems first. Even in small shops there is usually one or more devices that they do their testing on before working on any others. In larger facilities sometimes it is a complete mock up (either virtural or real) of the entire system.
Then move on to the redundant/backup systems next. (often they are the same as the test systems perhaps that is why Dale didn't differentiate)
Two big items he didn't stress.
Document Document Document
and
Tell everyone exactly what you are doing and when.
Start with light scans
I use NMAP TCP connect with the fast scan to start
Add port 502, 2222 and 44818 into the list for the fast scan. (there are others dependant on your vendors)
If you are not specifically defining the timing chose the polite scan. (it really doesn't matter that much if you are only hitting a few systems)
It is almost never a good idea to scan entire subnets unless you have already successfully done dozens of other checks and know the network can handle it.
I think I will continue this when I have the time.
.
Subscribe to:
Post Comments (Atom)
1 comment:
I have a colleague at work who often points out that many things "treated with sufficient neglect" will run for a very long time. In other words, it works --don't pick at it!
I've heard from others in the security business who have personally observed that more systems are damaged through patch-happy policies than from actual attacks or software failures. What I'm getting at, and what many people fail to notice, is that there are risks associated with doing nothing and there are risks associated with invasive scanning.
The reason many systems need to be scanned is bacause they have lots of opportunities for rougue software to invade the system. However good physical and network policies can keep this from happening. The difficult part is saying NO! to the IT and office commando types who feel the world owes them a view of everything from their desks.
I happen to believe that there are far too many interfaces in to today's DCS and SCADA systems than there should be. We have a saying in our company: When asking for data, if you ask for all of it, you will get NOTHING. Anyone who asks for all data clearly doesn't know what he or she is looking for. We will not tolerate data surfing. That's not what a control system is designed for and that's not how we sized it.
If people want such security so that they can surf anywhere in the system, then they need to be made aware of the costs and risks. These include extra security features for operators and making the system harder for everyone to use and evaluate. At some point we need to draw the line and say to the world "Get a Life!"
Post a Comment