Tag Archives: IT

Security through Obscurity

20120223-085142.jpg

There was a time when computer programmers on IBM’s midrange platform joked about “security through obscurity.” The data and programs were safe mainly because so few people knew how to get into them. Even if a hacker found a way to connect, the platform architecture was unique and the boxes were priced out of reach for the hacker demographic, preventing experimentation.

The low-hanging fruit for the hackers was on a different platform, machines running Microsoft’s Windows. They knew those machines well enough.

And so programmers didn’t worry as much about security on the IBM midrange machines as the programmers on other, better-known machines did. The lack of public knowledge served for purposes of security and virus prevention.

There was a downside to obscurity though. The midrange programmers watched as sales of their machine stagnated and companies switched to the more popular Windows based systems in spite of security concerns. The job market for midrange programmers shrank and wages fell.

Obscurity turned out to be just another word for unpopular.

Image: “Cavern carved by the sea in an ice wall near Commonwealth Bay, 1911-1914”
Source: State Library of New South Wales

Advertisements

Collaborate!

My favorite thing about collaborative software and techniques is the ability to quickly assemble and coordinate an ad-hoc cross-functional remotely diffuse team to work on an urgent or important problem.

Imagine a situation at a manufacturer where a production line has gone down due to the failure of a key computer application. A person in IT is notified by a worker on the line. The collaborative software is used to create a document that describes the problem and a high priority is assigned. The IT worker assigns appropriate troubleshooting resources via the software: maybe a techie to check the hardware, someone to check the network connection, someone to investigate the interface between an in-house written entry program and the ERP packaged software provided by an outside vendor (who might also be tapped for input). Notifications and alarms are issued.

All of these people report back or can ask questions via the collaborative software, keeping a centralized record of progress on these steps.

People on the line are granted access to the problem document as needed and are subscribed to all updates as they occur. They can answer or ask questions. Managers can be subscribed so that they can monitor progress and can easily see which parties are involved and whether the crisis is getting the appropriate attention and resources. People who manage relationships with outside stakeholders – perhaps a customer whose shipment may be delayed or a vendor whose product may be faulty, are included. Anyone who needs to be kept in the loop is easily added.

Troubleshooters can address the entire group instead of playing phone tag with individuals and hoping that information is relayed to the correct parties.

Everyone’s roles and behaviors become easier to discern. I’ve found that the people who have a tendency to disrupt meetings and discourage the input of others with sarcasm or bullying tend to monitor themselves better when their comments are self-documented. These controlling tendencies are visible to all and can be confronted and coached if bad behaviors surface here. This makes it easier for the entire team to focus on the problem at hand, minimizing the interpersonal dynamics or conflicts that might occur in a more private setting.

Individuals who hoard knowledge become more apparent as do the knowledge sharers. Stellar performers can be lauded and thanked right there in front of everyone involved.

The entire process is self-documenting and becomes a source of knowledge should a similar problem occur later. The document can become a repository for evidence: a place to attach PDF copies of reports, emails, affected vendor or customer info, notes, links to similar problems, checklists, etc. It becomes a workspace, lab report, and agenda. If further action is needed to prevent a reoccurrence of the problem, the document becomes an invaluable resource. It formalizes problem solving, notification procedure and evidence retention. Problems are less likely to be band-aided and forgotten. It becomes more possible to trace the root cause of secondary problems that sometimes arise due to the unforeseen consequences of a bad ‘fix’ of the original problem.

The entire process is self-documenting and becomes a source of knowledge should a similar problem occur later.

Integrated with best practices from a discipline such as ITIL, this type of collaboration can reduce the number of critical incidents in an organization, allowing everyone a breather from constant firefighting so that the organization can focus on becoming more competitive and effective, rather than focusing on just keeping the lights on.

20110620-052449.jpg