One of the constant challenges I face delivering big systems is meeting the protective monitoring requirements.
A lot of the requirement to spot technical events (low level network probing, back door installation, beaconing and command and control channels) can be covered with a bundle of vendor products integrated into a correlation engine that is tuned by an analyst and watched by expensive security operations staff. That isn’t easy, and getting the buy-in for the capital and operational investment definitely isn’t easy. However it is significantly easier than building a protective monitoring capability that understands the business transactions flowing through a system, significantly easier than finding an analyst who has the skills and time to understand the business rules for those transactions and what the indicators that those business rules have been breached are.
It occurs to me that we have a ready supply of staff on our internal or B2B transactional systems who understand the business context of the transactions intimately….the users!
We have staff in open plan offices, we give them ID badges to wear and ask them to challenge people they don’t recognise for ID. When these staff see something suspicious happening in their work areas they tell us. We put guards on the front door to limit the flow of unknown people into the office, we build secure physical perimeters and monitor them with guard patrols and CCTV. Generally we don’t do this in the offices themselves, we rely on the staff themselves to monitor the inside of our offices for security. This works because they can see what is going on, they can identify co-workers and they know from experience how their business processes work around them. Why not add this visibility and reporting capability to our big transactional systems?
If you’re in a particular team and you could see what your colleagues are doing on the system while you are working on it there is a good chance you would spot something unusual. Such as working a task assigned to a different team member, such as being logged on while home ill, such as making transactions at a much higher rate than the business process usually allows for, such as a user performing a transaction that the rest of the team have never heard of before or is usually working in a different team.
I suggest that for each transaction a short (A familiar 140 character limit perhaps) description is shown in a river of events at the side of the screen, including a user photo, a user name, what transaction type is being performed, on what data, when it was performed and where the connection to the system came from. Next to each transaction put a ‘Looks suspicious’ button that when pressed sends an alert to the security operations staff to investigate.
The alert can be automatically enriched by the protective monitoring software to include more details about the suspicious transaction, the user that initiated it and the user that indicated it was suspcisious. Such alerts could be weighted by the analyst on the criticality of the transaction and on the relative histories of both the transaction user and the alert initiator. Do either of those users have risk indicators visible in their past behaviour?
This outsources the task of identifying what might be interesting to review out to the users who have the knowledge of what normal looks like.
As long as the private data in the transaction is protected then there is no real privacy difference between this and working in an open plan office.
