Leader's Survival Guide Class in Jacksonville, FL

The Leader's Survival Guide class is coming to Jacksonville.

Leader's Survival Guide
Wednesday, July 16 and 23, 7-9pm
8447 Manresa Ave, Jacksonville FL 32244

This class is a version of the course I taught earlier this year at the LOPSA conference in New Jersey. The class there was well-attended and well-received. We are not charging an entrance fee, but donations to support our hosts are always welcome.

If you will be attending, please send an email RSVP to pr_communications@bbuuc.org so that we can set the room up properly.

The main difference between this course and the one I taught in New Jersey (aside from the cost) is that we will have two 2-hour sessions rather than a 3-hour marathon. The more relaxed pace should allow for good discussion and a chance to drill down on topics of interest.

The course is built around common-sense approaches to problems facing leaders, particularly at a small group level. The main topics are:

• Characteristics of a good leader
• Tools for effective management
• Starting off right--transition planning and execution
• Building a team
• Expectations and relationships
• Creating a learning plan
• Achieving early wins
• Matching strategies to the situation
• Time management
• Taming the meeting monster
• Project management
• Documentation, policies and procedures
• Managing people

"The Technology Manager's Survival Guide" Class at LOPSA East 2014

I had a blast this week teaching "The Technology Manager's Survival Guide" at LOPSA East 2014. The course was based on significant content out of "From Techie to Boss" and featured a lively conversation about the experiences of the technical managers in the audience.

If you were in the class, please feel free to contact me with any questions or comments.

I'll be presenting a similar class "Leader's Survival Guide," in Jacksonville, FL on July 16 and 23. Space for that class is limited; please contact me if you are interested in attending!

I am pursuing other opportunities to present the course; keep an eye on this space!

Protection against WiFi Viruses and Attacks

Security researchers have designed a virus that spreads silently through WiFi networks. The "Chameleon" virus replaces access point firmware and masquerades the settings and administrative credentials, which makes it very difficult to detect this virus.

Fortunately, the virus can be blocked by following good WiFi security practices. Unfortunately, many WiFi networks are not set up in a secure way.

Fortunately, the steps to secure a home WiFi network are not particularly difficult:

• Use AES encryption. WEP encryption and TKIP encryption have known weaknesses that are easily exploited. (Depending on your router, you would choose WPA2 or WPA encryption and select AES as the standard.)
• Use a password that is hard to break. It should have more than 20 characters, and should include a mix of upper and lower case letters, numbers, special characters, and even spaces. Entire sentences may be appropriate, if they are not publicly known.
• Change default administrative password and IP address. A surprising number of home installations still use the defaults.
• Turn off remote administration features. Administration should be required to be done over a wired connection.
• Verify that your firmware is updated. There are a number of bugs that have been reported against WiFi router firmware.
• Log out of your administrative sessions when you are done.

Beyond securing your own routers, you need to keep in mind that public routers may also have been infected. There are some steps you can take to protect yourself when connecting to public WiFi routers. Be aware that public networks are by definition insecure, whether WiFi or wired. There is little or nothing to stop a miscreant from trying to snoop your connection.

• Enable built-in firewall features on your computer, especially software firewalls. Deny all incoming connections.
• Make sure file sharing is turned off.
• Be aware that passwords may be sniffed by keyboard loggers, pulled from your computer's registry, or simply observed over your shoulder. By using a tool like LastPass or Password Safe, you can avoid having to type passwords while storing them in a secure, encrypted location.
• Use a VPN if possible.
• Use https (HTTP over SSL) to connect to vendor sites wherever possible.

Upcoming Events

I look forward to seeing some of you at an upcoming class.

My class, "Technology Manager's Survival Guide" is on the Friday afternoon training schedule at LOPSA-East on May 2 in New Brunswick, NJ.

And I'll be presenting a two-part class, "Leader's Survival Guide," in Jacksonville, FL on July 16 and 23.

Allowing Outside Vendors on Your Network

Recent revelations about the Target attack have re-focused attention on the dangers associated with allowing an outsider on your internal network. There are a few key lessons we can take from this episode:

• Use strong authentication. Passwords just don't cut it in today's environment.
• Segment your network properly. It appears that Target did not fence off its HVAC vendor from its Point of Sale (POS) systems.
• Require background checks. If you require background checks for your own employees before they are on your network, your outsourcing contracts should require the same level of checks from your vendors.
• Monitor traffic on your network. Network segmentation errors will occur, but hopefully someone would pick up on SQL Injection attacks from your HVAC network.

Bring Back Net Neutrality

In January, a federal appeals court struck down the FCC's regulations regarding net neutrality. In arguments in that case, Verizon indicated that it wanted to pursue "different pricing service models."

(In other words, they want to throttle traffic for content providers who don't pay up. In fact, they want it so badly that they stated it five separate times during arguments.)

In the wake of the ruling, it appears that Verizon is doing exactly that. Reportedly, Verizon reps are telling customers that the reason that services (such as Netflix) that run on Amazon's AWS platform run so slowly on Verizon's network is that they are being throttled.

(Verizon is clearly betraying its New Jersey roots. "That's a real nice service you're offering there. It would be a real shame if something happened to it." Who knew that they had hired Tony Soprano to plan their corporate strategy?)

Earlier this week, House and Senate Democrats introduced legislation to re-institute the former net neutrality rules. The legislation is known as the Open Internet Preservation Act.

Good luck to them. Given that most people have a very limited selection of broadband providers, I'm not sure how the FCC ever considered them anything other than common carriers.

Interview Tips

Career Builder posted a press release that outlined several major turn-offs during a job interview. It is well worth a read.

The article includes results from a survey of hiring managers. 87% of hiring managers have formed their opinion in the first 15 minutes, mostly based on non-verbal body language cues. Here are some body language pointers from the survey results:

• Make eye contact. 70%
• Smile. 44%
• Use good posture. 35%
• Don't fidget in your seat. 35%
• Don't fiddle with items. 24%
• Handshake that is strong enough. 27%
• But not too strong. 5%
• Crossing arms over chest (closed body posture). 24%
• Touching hair or face. 24%
• Appropriate use of hand gestures. 10%

Here are some other pointers from the survey participants:

• Be engaged and interested in the conversation. 55%
• Dress appropriately. 53%
• Avoid arrogance. (Stick to facts and figures. People know when you're inflating your role.) 53%
• Don't speak negatively about others. (This is about you; stay positive.) 50%
• Turn off your cell phone during the interview. 49%
• Inform yourself about the company and the opening. 39%
• Back up your statements with evidence. Use facts and specific examples. 33%
• Ask appropriate questions about the opening. 32%
• Limit the amount of personal information revealed; this is about your qualifications, not your personality. 20%
• Do not ask the hiring manager personal questions. 17%

The survey also revealed some howler mistakes by interviewees. You should steer clear of these.

• Answered a phone call about an interview with a competitor.
• Pulled out teeth while asking about dental benefits.
• Crashed car into building.
• Interviewee reported that valium was impairing her presentation.
• Acted out a role from Star Trek
• Set fire to interviewer's newspaper.
• Kept headphones on during interview.

Secure Application Deployment in the Cloud

The cloud provides a great way for a company to push infrastructure costs to an external vendor. But things that are minor for a locally hosted application could become a huge security hole when hosted externally.

Some key issues to look at when moving an application to the cloud include:

• Communication channels to services and systems the software relies on.
• Communication channels used for necessary communications to clients.
• Encryption standards for data at rest.
• Logging, log reviews, and monitoring.
• Authentication and access control.
• Privacy policies.

A lot of the security scrutiny surrounding a cloud migration focuses on the security of the cloud provider's infrastructure itself. This is important, but the weaknesses that the software platform brings along with itself are almost certainly a bigger problem.

Communication Channel Security

The key considerations here have to do with the nature of this communication. Certain types of data should not be transmitted unencrypted across an external network. This includes information protected by the privacy policy and relevant regulations, but it may also include information that would tell someone how the application works.

There is really very little incentive not to encrypt all traffic. There is a performance hit, but the only responsible way to avoid it would be do perform a close analysis of all data that would not be encrypted. Even when the analysis was complete, you can't guarantee that the program won't change in a few months (even assuming that nothing was missed in the analysis). There are a number of options for forcing encrypted traffic, including built-in capabilities in both Java and .NET to force use of SSL for web interactions.

Where programs have incorporated hard-coded IP addresses in code, there is some possibility that traffic would be delivered to entirely the wrong place in a hosted environment. This is especially the case for the standard ranges that are commonly used for internal IP addresses.

But the use of hostnames can also be problematic, since name lookup infrastructure is usually controlled by the outside vendor. (In any case, references to specific names should be contained within configuration files, not in the actual code source.)

Where possible, client-side SSL certificates can provide an extra layer of security, by providing assurance that the target side of the connection is actually the system that we are trying to contact.

Data Encryption

Data at rest can be secured using several technologies, some of which overlap. SQL Server and Oracle both provide Transparent Data Encryption (TDE), and DB2 provides similar functionality. Make sure key sizes are in line with current best practices recommendations.

Queries to databases can be encrypted during transmission by specifying SSL as the connection protocol in the JDBC driver or .NET connection.

Keep in mind that existing hard-coded encryption tokens, keys, etc may cause problems during application migration to the cloud. And if the same key is re-used in several contexts, the compromise of a single component can result in a broader compromise through the entire application or environment. It is important that encryption keys, tokens, etc be maintained outside of the code base itself, where they can be changed or updated as needed.

Logging Considerations

Logging streams usually do not use connection-oriented protocols. One concern about logging in the cloud is that logging streams are relatively easy to divert or snoop. Debug-level information might be considered an information leak about how the parts of your application communicate, which could provide the information an attacker needs. While we need to allow an adequate level of logging, we may also want to restrict access that would allow too high a level of logging to be enabled.

At the same time, it is important that logs be maintained and reviewed, just as they should be on an internal network. Given the potentially greater exposure of the data, log review procedures need a careful review as part of any application cloud deployment.

Effective System Monitoring

In order to maintain a reliable IT environment, every enterprise needs to set up an effective monitoring regime.

A common mistake by new monitoring administrators is to alert on everything. This is an ineffective strategy for several reasons. For starters, it may result in higher telecom charges for passing large numbers of alerts. Passing tons of irrelevant alerts will impact team morale. And, no matter how dedicated your team is, you are guaranteed to reach a state where alerts will start being ignored because "they're all garbage anyway."

For example, it is common for non-technical managers to want to send alerts to the systems team when system CPU hits 100%. But, from a technical perspective, this is absurd:

• You are paying for a certain system capacity. Some applications (especially ones with extensive calculations) will use the full capacity of the system. This is a GOOD thing, since it means the calculations will be done sooner.
• What is it you are asking the alert recipient to do? Re-start the system? Kill the processes that are keeping the system busy? If there is nothing for a the systems staff to do in the immediate term, it should be reported in a summary report, not alerted.
• If there is an indication (beyond a busy CPU) that there is a runaway process of some sort, the alert needs to go to the team that would make that determination and take necessary action.

In order to be effective, a monitoring strategy needs to be thought out. You may end up monitoring a lot of things just to establish baselines or to view growth over time. Some things you monitor will need to be checked out right away. It is important to know which is which.

Historical information should be logged and retained for examination on an as-needed basis. It is wise to set up automated regular reports (distributed via email or web) to keep an eye on historical system trends, but there is no reason to send alerts on this sort of information.

Availability information should be characterized and handled in an appropriate way, probably through a tiered system of notifications. Depending on the urgency, it may show up on a monitoring console, be rolled up in a daily summary report, or paged out to the on-call person. Some common types of information in this category include:

• "Unusual" log messages. Defining what is "unusual" usually takes some time to tune whatever reporting system is being used. Some common tools include logwatch, swatch, and logcheck. Even though it takes time, your team will need to customize this list on their own systems.
• Hardware faults. Depending on the hardware and software involved, the vendor will have provided monitoring hooks to allow you to identify when hardware is failing.
• Availability failures. This includes things like ping monitoring or other types of connection monitoring that give a warning when a needed resource is no longer available.
• Danger signs. Typically, this will include anything that your team has identified that indicates that the system is entering a danger zone. This may mean certain types of performance characteristics, or it may mean certain types of system behavior.

Alerting Strategy

Alerts can come in different shapes, depending on the requirements of the environment. It is very common for alerts to be configured to be sent to a paging queue, which may include escalations beyond a single on-call person.

(If possible, configure escalations into your alerting system, so that you are not dependent on a single person's cell phone for the availability of your entire enterprise. A typical escalation procedure would be for an unacknowledged alert to be sent up defined chain of escalation. For example, if the on-call person does not respond in 15 minutes, an alert may go to the entire group. If the alert is not acknowledged 15 minutes after that, the alert may go to the manager.)

In some environments, alerts are handled by a round-the-clock team that is sometimes called the Network Operations Center (NOC). The NOC will coordinate response to the issue, including an evaluation of the alert and any necessary escalations.

Before an alert is configured, the monitoring group should first make sure that the alert meets three important criteria. The alert should be:

1. Important. If the issue being reported does not have an immediate impact, it should be included in a summary report, not alerted. Prioritize monitoring, alerting, and response by the level of risk to the organization.
2. Urgent. If the issue does not need to have action taken right away, report it as part of a summary report.
3. Actionable. If no action can be taken by the person who receives the alert, it should have been defined to be sent to the right person. (Or perhaps the issue should be reported in a summary report rather than sent through the alerting system.)

Courage in a Corporate Setting

Sometimes leaders need to leave their comfortable "safe zones" in order to be effective. The reality is that the bulk of our jobs can be done by almost anyone. Most decisions we make are of the "no brainer" variety, especially as we become more experienced and comfortable in our role as leaders. But there are a few decisions that we need to make where we really earn the money and privileges that come with a management role.

When we voluntarily step outside of our comfort zone to do what we know to be right, we demonstrate the courage that distinguishes between someone who is a leader and someone who is merely a boss.

Battlefield analogies are very common when we speak about courage. An article by Peter Voyer in Ivey Business Journal suggests some important leadership traits that translate from the battlefield to a corporate setting:

• Don't ask subordinates to do something you would not do. Not only should you be willing to work alongside your team, you should be seen as someone who engages in the task at hand. (Of course, the way you engage the project will be somewhat different than the tasks you would assign a junior team member, but nobody on your team should feel like you are unwilling to dirty your hands to make the project succeed.)
• Demonstrate moral fiber. You can lose years of built-up moral capital in a split second with a morally dubious decision.
• React quickly, decisively, and fairly when presented with a moral question.
• Maintain dignity and respect within and between groups.

I recently saw an article about a manager who was allegedly fired because he stood up for an Indian employee's right to earn the same salary as American employees with a similar job. This is the sort of courage we need if we want to be leaders and not merely bosses. Who do you want to see when you look in the mirror in the morning?

Great leaders earn the loyalty of the people who work with them. They earn loyalty by demonstrating loyalty. This doesn't mean that you cover for one of your subordinates who does something wrong; it does not help someone's development to infantilize them. But make sure that the consequences are fair and are implemented with the long-term development of your employee in mind. This may mean that you stand up for someone who has made a mistake and demand fair treatment for that person. Yes, this is uncomfortable, but it is part of how you become the manager you want to be.

Make sure you stay informed of your team's progress towards goals, and work with them to overcome obstacles. This does not mean that you do your team's work for them; it means that you provide a sounding board. Sometimes a problem is escalated to you if it is something that requires a manager's approval or advice; make sure that you do what you need to do promptly, then return the task to its rightful owner.

Maintain your integrity. Make the best decisions you can, and abide by the results of those decisions. Don't pass the blame. Instead, identify how to fix the situation and propose solutions.

Demonstrate courage by making the right decisions, even when they are hard. Anybody can be a great boss when the going is easy. Being a great leader comes from doing the right things even when they are not easy.

The Promise and Peril of Self-Driving Cars

The research by Google and others into self-driving cars has been intriguing. The vast majority of traffic accidents are the fault of drivers, and being able to eliminate human error would be a huge win for traffic safety.

But if computers are driving cars, we have to take a serious look at information security in the context of a self-driving automobile. Unfortunately, most current automation does not have adequate safeguards to protect from malicious inputs.

In particular, components do not do checking or validation to make sure that commands are being issued from an appropriate source. Security researchers have demonstrated that they are able to issue commands to a Prius to control steering, braking, acceleration, and dashboard displays. They were also able to disable an Escape's brakes at slow speed.

Ford and Toyota both point out that the researchers were connecting directly to the car's CAN (Controller Area Network), which limits the impact of some of their demonstrations. But keep in mind that wireless controllers on on-board systems such as Bluetooth controllers on sound systems and telematics units on satellite roadside assistance services may provide an entry point into the automobile. Anywhere a wireless connection allows access to a component connected to a CAN is a possible entry point for malicious code.

The sorts of security measures we use for other network-connected items would still work inside a car. Provide air gaps between components that don't need to be connected. And provide for validation and authentication of commands from components that do need to be connected.

I remember discussions about PC security in the early days of the Internet, when most computer viruses were still spread by injudicious insertion of floppy disks. Way back when, we were told that PCs didn't need to have security programmed in from the ground up. I'm hoping we learn from the history of those poor decisions. A Blue Screen of Death is one thing, but a traffic fatality is another.