Showing posts with label Incident Management. Show all posts
Showing posts with label Incident Management. Show all posts

Wednesday, July 22, 2015

Never trust a subcontractor

It all started with a phone call. "The whole network at [customer redacted] is down and they have no power - they need your help."

My blood ran cold. The engineer calling me sounded panicked, and for good reason. [Customer redacted] has an enormous natural gas facility in South Texas, too far from civilization to get enough power off of the grid. We designed and built an onsite natural gas power plant for them - a big one, capable of supplying 40+MW of power at peak load. They could run the facility for a short while without the power plant, but not long - and shutting down the facility meant losing 7 figures per hour. By the time I was informed, they had 6 hours until they had to shut down.

As the guy who had designed and installed said network, I was naturally the guy to call when it had problems, which had never happened before. It was a pretty simple network, honestly - just switches, cat5 cables and fiber. Since this was the network all the PLCs, relays, meters and whatnot ran on, it was airgapped & isolated, no routers. Not much to go wrong.

I quickly get on the phone and walk the guy on their end through plugging in a laptop and running
some simple tests. Check lights on things, ping this, ping that. Everything seems good, though. The network is emphatically not down. So I send him a remote app and take control of his laptop to see for myself.

Log into switches, check things, nope, the network's not down. When I log into the HMI system, though, I see a big red error message: "Network Error: Cannot connect to database". The database server is up, though. I log into the database server (Windows Server 2012 running MSSQL) and that's where I find the problem: SQL isn't running. I try to start it and it immediately shuts back off.

Thursday, October 21, 2010

Security Incident Response Team: CSIRT: Getting Start

Action List for Developing a Computer Security Incident Response Team (CSIRT)
  1. Identify stakeholders1 and participants.
  2. Obtain management support and sponsorship.
  3. Develop a CSIRT project plan.
  4. Gather information.
  5. Identify the CSIRT constituency.
  6. Define the CSIRT mission.
  7. Secure funding for CSIRT operations.
  8. Decide on the range and level of services the CSIRT will offer.
  9. Determine the CSIRT reporting structure, authority, and organizational model.
  10. Identify required resources such as staff, equipment, and infrastructure.
  11. Define interactions and interfaces.
  12. Define roles, responsibilities, and the corresponding authority.
  13. Document the workflow.
  14. Develop policies and corresponding procedures.
  15. Create an implementation plan and solicit feedback.
  16. Announce the CSIRT when it becomes operational.
  17. Define methods for evaluating the performance of the CSIRT.
  18. Have a backup plan for every element of the CSIRT.
  19. Be flexible.