Tag Archive - blueprints

There Are Many Ways We Learn

learning logo 300x300 There Are Many Ways We LearnThere are many ways to learn. We learn from theory, observation, and our own practical experience. Regularly, emotions deepen learning, especially when a comment or an experience hurts or pleases, offering new insights and generating new ways of coping with a challenge. Lessons that fit one’s character may be easier to understand, but in the end the ones that surprise us, that don’t fit our usual patterns, are more likely to be remembered. Of course I learned from every supervisor I’ve had…through positive and negative examples. I can’t, however, really say that I learned this or learned that directly from the advice of a boss.

Good advice, I think, often emerges from discussions, particularly ones that are more reflective or relaxed than normal. During these kinds of conversations, learning occurs in an osmotic way. In fact, later on you find it difficult to recall the exact context or details of the conversation itself, but from it you absorb a piece of wisdom that stays with you for a lifetime.

I’ve had several experiences like this at very different periods in my life. Let me share one example. This incident occurred during a time I had spent working in quality control for an aeronautical engineering company. Every morning our team began with a short meeting, what we called the ‘morning roundup’. We programmers and operators coming on duty were briefed about what had happened at our plant overnight, and we heard about the new blueprints and materials. We figured out what needed to be done that day and who should be responsible for what. The meeting was conducted in a highly disciplined manner; my boss disliked it profoundly when people came in late. In fact, being tardy was unacceptable. One winter morning, however, the weather was horrible, and the roads were covered with ice and snow. As I drove to work, I realized I hadn’t left enough time. Arriving at the meeting 15, maybe 20, minutes late, I was embarrassed and began apologizing as I sat down in the conference room. But my boss interrupted me. “On a day like today,” he responded, “only stupid people are on time.” That one remark had a deep impact on me. It made me realize that sometimes the generally accepted, traditional rule is the worst possible one to follow. When we’re setting priorities in any situation, we have to look at their relative importance and at the circumstances. And we have to be willing to change our own rules.

My boss was offering an opinion and, the insight I gained came not in the moment itself or from what was said but from stepping back, from thinking about what had happened, from pondering what I had been told and how I had reacted emotionally. Situations like this continue to affect me practically…to influence how I act while working, how I evaluate options and alternatives, and how I analyze myself and my actions. My experience being late that morning years ago has given me a lifelong tolerance for mistakes…my own and others…as what may appear at first to be a mistake might sometimes be the only right way forward. It also has made me empathetic toward employees when, for example, they are conscientious and make an effort but, for whatever reason, don’t manage to get a task or project done. It has taught me to reconsider the appropriateness of my own rules from time to time and to review them in the light of changing circumstances.

As any entrepreneur, we are keenly aware of the limits of your knowledge and expertise. We can never master every situation or specialty; we constantly have to seek help from experts in other fields. We admit our lack of knowledge to anybody we think can help us. But when we’ve gotten the facts and know what’s wrong with the system, we must be confident enough to go ahead and take appropriate action…even if others doubt us or express divergent views…because decisive and rapid action can mean life or death for an opportunity. In business, the stakes may not be life or death, but clear, disciplined thinking and prompt action are often vital to success.

Recent Information Security Task

TheSecurityCycle 300x297 Recent Information Security TaskA client called me up the other day and asked me to come to his office. Once I arrived, he asked me to install a firewall so that his network would be secure. I asked him for his company’s security policy so I could configure the firewall. He gave me a curious look and asked, “What do I need that for?” In the years since the explosion of the Internet, this response is still the rule rather than the exception. Companies have comprehensive employee policies, sometimes filling two inch binders, but do not have information security policies. If they do, they will hand you 5 sheets of paper that cover the assets of a multimillion-dollar corporation. Just as employment policies describe the practices that employees and managers must take, security policies describe how the company wants to protect its information assets. That is an important concept to remember: Information is an asset. You might not be able to assign it a value, but your competitors might pay thousands or even millions of dollars to understand or even steal those assets.

Information security policies are high-level plans that describe the goals of the procedures. Policies are not guidelines or standards, nor are they procedures or controls. Policies describe security in general terms, not specifics. They provide the blueprints for an overall security program just as a specification defines your next product. Questions always arise when people are told that procedures are not part of policies. Procedures are implementation details. A policy is a statement of the goals to be achieved by procedures. General terms are used to describe security policies so that the policy does not get in the way of the implementation. For example, if the policy specifies a single vendor’s solution for a single sign on, it will limit the company’s ability to use an upgrade or new product. Although your policy documents might require the documentation of your implementation, these implementation notes should not be part of your policy.

Although policies do not discuss how, properly defining what is being protected assures that proper control is implemented. Policies tell you what is being protected and what restrictions should be put on those controls. Although product selection and development cycles are not discussed, policies will help guide in product selection and best practices during development. Implementing these guidelines should lead to a more secure system.

When management participates in the creation of information security policies, it demonstrates that management supports the effort, lending credibility to the entire security program. Having management support is always important. Without leadership, employees will not take policies seriously. Therefore, if you do not have the support of your upper management, your program is doomed to fail before you finish writing the policy.

First you can try to reason with them. You can point out that the systems and data have real costs. You can demonstrate how an outsider or a disgruntled insider can easily access sensitive information that could damage the company’s business functions. You can show them studies, articles, even this book. But if this doesn’t convince them, you might have to wait until your first disaster.

Management might say that everybody is responsible for his or her own security. That might work in the short term, but it prevents the company from working with itself. If one department uses one standard and another department uses another standard, interoperability could be a problem. Policies ensure that the company uses the same standards in every security instance. This consistency makes it easier for the company to integrate, interact with customers, and maintain a sense of security throughout the system.

Finally, an information security policy will help avoid liability. We live in a litigious society. If you try to enforce rules that are not expressly written, you will be sued. If you fire an employee for security violations that have never been written, presented to the employee, or previously enforced, that employee also can sue your company. I know it sounds harsh, but the reality can be devastating when the subpoena arrives.