Question
A successful cheese dairy has digitalised everything — production, logistics, sales — but never took cyber security seriously: "what could possibly happen in a cheese factory?" Which cyber systems would you actually find there?
Answer
Far more than the office PCs — every business area runs its own, from the plant controller and the milking robot to the ERP, the web shop and the cold-chain sensors.
* Walk the business areas and the estate turns out to be ten times what management would have named. *
Walking the business areas of a mid-sized dairy turns up something in each:
| Area | Cyber systems you would find |
|---|---|
| Production | Control system for the cheese-making plant; database of ingredients and recipes; milking robots, pumps, bottling/filling equipment |
| Purchasing / supply chain | B2B web server for suppliers; cold-chain traceability; animal tagging (chipping), GPS trackers for pastured animals, drones |
| Administration & management | Intranet; PCs, notebooks and smartphones; accounting system (e.g. SAP); the basic IT infrastructure |
| Logistics, storage, delivery | ERP for stock management; sensors in the warehouse (temperature, humidity) |
| Sales & distribution | The company website; a cheese web shop; the customer database |
The point of the inventory is the surprise itself. Asked to list "our IT", the dairy's management would name the notebooks and the accounting system — perhaps a tenth of the list. The rest entered the company as machines and equipment, bought by production and logistics, installed by vendors, and never registered as computers at all.
Tip: this is the first move of any real analysis, and it is deliberately boring: before you can secure an estate you have to enumerate it, business area by business area, asking "what is used here, and what is done with it?" Every asset nobody names is an asset nobody patches.
Go deeper:
CIS Control 1 — Inventory and Control of Enterprise Assets — why the dullest control is the first one: everything else is scoped by what you know you have.
Note saved — thanks!
Question
In the case of the home-made "service number" authentication, why is the protection weak, and what should be done?
Answer
A secret service number passed as a parameter easily becomes common knowledge: it gets shared, people who change jobs or leave still know it, and it can be found by reverse engineering or brute force. Proper access protection (AAA) is needed, and the developer should understand the weaknesses so obscurity isn't reused next time.
The case: developer E wrote a web service that produces business forecasts. Each call triggers heavy computation, so to avoid unnecessary load he only runs it when a particular service number is passed as a parameter, and gives that number to a few selected users.
Why the secret leaks:
- it is easily passed on,
- employees who change roles take the knowledge with them, and former employees may still know it,
- reverse engineering or simple brute-force guessing can reveal it.
What to do:
- set up real access protection (AAA security),
- work through the case with the software development team: E was thinking of server load (and maybe cost), but not of security requirements such as preventing unauthorised access to the forecast data,
- show E what weaknesses his "protection" has, so the next project does not rely on security-by-obscurity again.
Note saved — thanks!