Well-written policies are the easiest thing in an assessment to accept and the most dangerous. Three cases where the document was good and the reality was not, and the habit that caught each one.
The policy said thirteen months. So did the database, from a different date.
A subscription business’s retention policy said card numbers were kept for thirteen months after the last payment. The database kept them for thirteen months after the card’s expiry date, which can be years later, and nobody had a strong reason why. The encrypted settlement files exchanged with the bank were also kept for thirteen months, where about ten days would have done.
The policy was fine. The database had never been asked whether it agreed. We run the query ourselves, on the live system, with the administrator watching. Not because we distrust the policy, but because a retention control is the query, and the policy is a description of what the query is supposed to do.
The reception that was staffed around the clock
A colocation provider’s documentation described a reception staffed twenty-four hours a day, visitor identification, continuous video recording and individual administrator accounts. On the day of the visit, nobody was at reception. We were not asked for identification. The video system had long stretches with no footage. There was one shared administrator account.
Our note at the time: the policy was well written, and the visit showed a gap between documented policies and actual practice. The provider had not lied. It had written what it intended, and nobody had gone to look.
A second data-centre operator had an out-of-hours “self-service” process that let clients bring visitors in with nobody on site, which quietly bypassed the visitor management process the documents described. Its local staff also had full rights on the video systems, so anyone could remove the record of a visit. Both findings came from standing in the building. Neither would have come from the documents.
Built, but not running
A payments platform wanted a Report on Compliance before it went live. There were no card transactions to observe. Change control had not started because the platform was in “build mode”. Network diagrams changed during the assessment. Segmentation was stated to be in place and had not been tested.
The first report listed many requirements as not in place, with scope that could not be validated as the first item. A PCI DSS assessment describes a running environment. Processes have to be shown as known and in use, not described in a document about how they will work. The platform went live, the processes ran, the test was done, and the compliant report followed two months later. The next environment from the same company, assessed once it was running, went through with a handful of findings.
What people get wrong
They prepare the documents and skip the room. The reception, the mantrap, the rack, the administrator’s screen. The assessor goes there because that is where the control is or is not.
They treat a design as an operation. A platform in build mode has designs. A platform in production has evidence. The standard asks for the second.
They let the policy own the control. A retention policy, a visitor procedure and a change process each describe something a system or a person does. The query, the log book and the ticket queue are the control. If they do not agree with the policy, the policy is the one that is wrong.
A platform in build mode has designs. A platform in production has evidence.