Welcome to codesecurely.org Sign in | Help

codesecurely.org

Rudolph Araujo's ramblings on the world, my life, my work and oh yeah security!
Considering Taking the CISSP? – Consider This!

I am a big fan of computer based training – I think the potential for this is enormous especially for organizations that are looking to train large numbers of their staff. One obvious advantage is the ability to scale easily across many employees and many sites. But another important and perhaps overlooked advantage is the ability to help students really gain confidence over the material, understand their weak spots, consider areas that they need to work on and finally prepare for any certification goals. They can also be used to simulate the real exam and provide results that can then feedback into a study plan.

Recently a close friend, Mano Paul, launched Express Certifications, a training and certification company focused on developing innovative testing and training solutions, one of which is the new training portal focused on the CISSP and the SSCP exams. This site is the Official (ISC)2 Practice Self Assessment provider and provides CISSP Practice Exams as well as SSCP Practice Exams. The main benefit this site provides is in helping you with gauging your readiness for the certification exam. One of the thing I like about it is that it targets not just the end result but also the preparation. The idea being you first assess yourself, figure out what areas you need to focus on, continue to work on those areas of weakness until you have perfected the material and then finally take the certification exam. And because the subscription to this site is not time limited, it allows you to prepare and give the exam at your own pace rather than allowing your preparatory material make the determination as to when you take the exam. One of the really cool things Mano has done with this site is to provide for rich reporting which can act as your personal study planner. Finally, it also simulates the experience of taking the real exam before you actually take it. Of course as you go through this entire process you can perform SWOT analysis and check your own personal readiness while watching all the time how you are trending towards your final goals.

There's also benefits to larger organizations attempting to certify some or all of their employees. The main thing perhaps is the ability to judge whether your employees are ready for the certification exam before investing in the cost of the exam itself. Further, even without the certification goals, the ability to view the competence levels of your employees in the different domains of security is in itself a great benefit for security teams. Finally, it is very competitively priced allowing both individuals and organizations to sign up at relatively low cost. In fact they offer corporate and affiliate that could provide advantages if signing up in volumes.

In any case, I am pretty excited by this offering and apparently so is perhaps one of the most discerning clients – the Department of Defense (DoD) - it uses this training portal to assess the readiness of their information assurance personnel as part of the 8570.1 directive. Good luck Mano J and good luck to all of you preparing for the CISSP / SSCP examinations. Hopefully this site can help with that endeavor.

For more details visit the site or use the contact information in the sidebar.

 

 

 

 

 

 

 

 

 

Securing ActiveX Controls

I was reading my buddy Alex Smolen's post the other day on Java Applet Security and figured I would see his post and raise it with a post on ActiveX control security. Actually, as you can probably see I have been slacking on the posting front so figured it is about time and this specific issue – ActiveX control security has been something I have been seeing a lot of in assessments but it doesn't seem to be covered enough in both the testing literature out there or indeed in secure development guides.

As it turns out, ActiveX controls are at the end of the day C++ or C# or (pick your favorite language) code so much of the guidance on secure application development continue to apply as you would expect. However, ActiveX controls obviously add another interesting dimension – they are mobile code and execute not on the server like typical web applications do but on the client machine. That means any vulnerabilities in this control place each and every one of your customers at risk. In fact with some popular ActiveX controls this is such a rampant problem given that they are installed on hundreds of thousands if not millions of computers across the globe. What perhaps exacerbates the risk even more is these ActiveX controls typically provide very powerful functionality by leveraging deep access into the client computer. This in turn can mean you are putting your users at risk even if you have no stereotypical vulnerabilities in your control code. Let me explain, why just not having buffer overflows and the like is not enough to protect your customers.

Well it all really comes down to the trust model and the sandbox built for ActiveX controls in the browser – Internet Explorer for the most part. Enter the notion as being "safe for initialization and / or scripting". The relevant MSDN documentation on this is shown here:

Initialization Security

When a control is initialized, it can receive data from an arbitrary IPersist*  interface (from either a local or a remote URL) for initializing its state. This is a potential security hazard because the data could come from an untrusted source. Controls that guarantee no security breach regardless of the data source are considered safe for initialization.

There are two methods for indicating that your control is safe for initialization. The first method uses the Component Categories Manager to create the appropriate entries in the system registry. Internet Explorer examines the registry prior to loading your control to determine whether these entries appear. The second method implements an interface named IObjectSafety on your control. If Internet Explorer determines that your control supports IObjectSafety, it calls the IObjectSafety::SetInterfaceSafetyOptions method prior to loading your control in order to determine whether your control is safe for initialization.

Scripting Security

Code signing can guarantee a user that code is trusted. However, allowing ActiveX Controls to be accessed from scripts raises several new security issues. Even if a control is known to be safe in the hands of a user, it is not necessarily safe when automated by an untrusted script. For example, Microsoft Word is a trusted tool from a reputable source, but a malicious script can use its automation model to delete files on the user's computer, install macro viruses, and worse.

There are two methods for indicating that your control is safe for scripting. The first method uses the Component Categories Manager to create the appropriate entries in the system registry (when your control is loaded). Internet Explorer examines the registry prior to loading your control to determine whether these entries appear. The second method implements the IObjectSafety interface on your control. If Internet Explorer determines that your control supports IObjectSafety, it calls the IObjectSafety::SetInterfaceSafetyOptions method prior to loading your control in order to determine whether your control is safe for scripting.

 

When it comes to ActiveX controls designed for the browser, it is more likely than not that these are marked as safe for scripting.

The problem is this approach is very binary – or in other words you can either mark an ActiveX control as never safe for scripting or always safe. Like we just said most developers will mark the object safe for scripting and all seems well. This is where it begins to get really interesting from a security perspective. A control marked as safe for scripting can be loaded by any and every web page developer whether they work for your organization or are the teenage, blackhat hackers down the street or in some dark basement half way across the globe.

Consider, now a familiar use case for an ActiveX controls – a control that lets you browse your local file system and add or delete files from / to the server. Developing this control just gave your company the award for most usable site on the entire World Wide Web and as they say business is good. Joe Hacker down the street is an avid user of your site and hence your ActiveX control realizes he might have a way to create a nice little botnet for himself through your ActiveX control. So here is what he does:

  1. Creates a phishing site that looks perhaps just like yours or indeed anything else.
  2. Within this site he loads your ActiveX control using the object tag he noticed in the HTML source of your website
  3. Uses the interfaces, methods, events exposed by your ActiveX control within his fake website
  4. You see where this is going, the more powerful your control the more power Joe Hacker has in his evil, evil hands …. Sigh L

So what is the solution you ask? As tempted as I am to leave that for another day and build on the suspense … I shall not J.

This is where the SiteLock template comes in. From the download page:

"The SiteLock ATL template enables an ActiveX developer to restrict access so that a control is only deemed safe when used in a predetermined list of domains. This limits the ability of Web page authors to reuse the control for malicious purposes."

Essentially SiteLock allows the developer to define a set of website domains (or Internet Explorer Zones) that are allowed to load this control. This information is built into the control itself and each time the control is loaded, it checks the site that is loading it to make sure it is part of the white list defined by the original developer. If not it will refuse to load. In fact SiteLock can also support "expiring" an ActiveX control after a certain time period. The idea being here is that functionality present in the ActiveX control can be disabled after a certain date. Both of these measures provide risk mitigation both against malicious (innocent as well actually) repurposing of your control as well as possibly lowers risk if the control were to have an unpatched vulnerability such as a buffer overflow. It is thus an excellent example of defense in depth and risk mitigation which is easy enough to code into the system and thus there is little reason for not doing so.

For the technically inclined the SiteLock template functions by providing its own custom implementation for the aforementioned IObjectSafetyIobjectSafetySiteLockImpl. This implementation provides the magic security sauce which does all the checking described in the previous paragraph.

References:

Designing Secure ActiveX Controls

Best Practices for ActiveX Control Updates

New Version of SiteLock Template

P.S. It is important to note that what has been discussed here bears no relation to whether the control is signed or unsigned which is what Alex's post talked about. Instead it focuses on the properties of a legitimate ActiveX control. The browser will still show the regular warnings whether the control is signed or unsigned depending on how your browsing security policy is defined. It will however NOT let you know if the site attempting to use an ActiveX control is legitimate or malicious – it really has no way of doing that. So as a developer your action item is to make sure all your controls that will be hosted in a browser are protected using SiteLock. If your controls are never intended to run in a browser do not mark them as safe for scripting. Internet Explorer does not load such controls so problem solved!

If you are a end user then make sure the controls you use have this protection or hound the developers if you can until they provide this protection. In the meantime, refuse to load ActiveX controls whether signed or unsigned from untrusted websites!

 

Courage

Again I know this is off topic but I had to share this. Thanks to my co-worker Jeremy Allen for sharing it with me. I did not have the opportunity to take any classes with this Professor while I was at CMU but I have heard of his work and what he has done at the Entertainment Technology Center. He rocks!

OT: Passes for the Halo 3 Launch Party

Censorship In The Air

At the beginning of the year I was flying to California and the movie playing on board was The Queen featuring Helen Mirren. At a number of times during the movie the word "God" shows up – after all the anthem of the UK is God Save The Queen and the movie did deal with the royals and the passing away of Princess Diana. Anyways a few weeks after that this news made its way around the Internet. The airlines came out saying it was the distributors fault. While the distributor accepted responsibility they blamed an overzealous rookie who was tasked with taking out profanities and blasphemy!

Well now it has happened again, I was on a plane today watching the Fantastic Four sequel and again there are a few more "Oh My God!" moments and all you hear is "Oh My"! I wonder how they will explain it away this time? I don't know if it's the same distributors or not but it will still be interesting to hear the explanation.

The interesting thing is I have a few friends who are atheists and agnostics and having spoken to them, none of them said they would be offended if the word "God" was NOT censored. So I am not really sure where this political correctness is coming from. More importantly none of the references I have seen are anything out of the ordinary – I mean it isn't like worship of a particular God or following a particular religion was being advocated. It's nothing you would not hear in a regular day to day conversation. In fact funnily enough in the case of the Queen incident, the movie was followed with a seemingly uncensored episode of The Office which had a fair few maturer themes as you would expect J.

Anyways I know this is bit of an off topic for me but still thought it was kind of strange!

Lessons in World Geography

Much has been made about poor Miss Teen South Carolina messing up on Geography and everything else remotely academic. But honestly if Google News (with all of its Ph.Ds and Mensa members), NBC and KTUU can think Iraq is in Africa then who are we to criticize ;).

P.S. Yeah I know slip of the tongue (or keyboard perhaps in this case) and all but still funny I think J. And yes I did check that he didn't *also* visit Africa. At least the article being linked to doesn't say so now. My guess is it originally mentioned Africa in the title and that's when Google indexed it but since then some editor at KTUU updated it and its only a matter of time before Google picks up the new version. Hence this screenshot to save it for posterity ;).

P.P.S. Yeah I know Google has nothing to do with this – but forgive my Google bashing for today J.

Implementing a Security Training Program

Having discussed the importance of security training and really its criticality – without security training most software security programs are doomed to failure – I wanted to spend a little bit of time talking about how to go about creating such a program. Really the expert at this is one of my co-workers Roman Hustad who hopefully will write in detail about this at some point (for now he is on a long hike to nowhere way up North J - lucky him!). Anyways most of this post is really inspired and attributed to things I have learnt from Roman.

Here's what we will talk about in this post:

  • Who needs to be trained?
  • How do you scale?
  • How to be effective and efficient?
  • How to measure success?

Who needs to be trained?

In a word "everyone". The bottom line is it is not just the developers who play a critical role in building software, there are a bunch of other roles involved in the process and all too often companies tend to ignore or entirely forget about the impact these other folk can have on your software security.

  • Let's start in the beginning: well the business – whether this is the product management teams in an independent software vendor or it is the business units who need the specific application being developed in an IT organization. The business must be trained on why this security thingie is important in the first place. Ultimately in some way they pay the bills and decide the schedules – they will therefore need to buy off on the concept that during the development process we will engage in security activities that seemingly provide no direct value at least in terms of functionality.
  • Secondly, the business analysts, requirements specialists or whatever it is that role is called – the people who write software requirements. It is essential that they understand how to document security requirements. They need to understand what the different organizational drivers for security are – whether these are specific regulations that must be complied with, industry specific standards, company policies and then security features themselves.
  • Next are the architects, designers and developers. This is where the bulk of the training investment will be made. Most of the other groups discussed here are relatively small and the quantum of information that they need to be provided with is not that large either. With this group really the sky is the limit and the training has to constantly be evolving as the security industry itself evolves. This group needs to be trained into secure design and architecture principles, secure coding practices (in each of the languages that they work with) as well as in performing threat models, doing code reviews and security unit testing. As you can see this could become a one year graduate program in itself J so we will discuss some strategies later in this post of how to deal with this.
  • Testers. For some reason everyone tends to forget these poor souls. Given that their charter is to test software, why not provide them with the training and tools to test the security of software?
  • Deployment and operations engineers are the next group. Responsible for installing and maintaining the application in production, software security training is critical to teach them how to configure and run the application securely. This is everything from the need to patch servers and third party components to the SSL configuration on the web server or from the secure configuration settings in the web.config or web.xml files to the service contexts and credentials.
  • Finally the users themselves. Security awareness is critical for the users in general because guess what even if their account for instance is compromised due to their mistake (perhaps they provided their password to someone claiming to be from your helpdesk), they will most likely still blame the application ("well no one told me that I was NOT supposed to give my password out! And they did say they were from your helpdesk!").

How do you scale?

One challenge that any company that is looking to implement a security training program runs into is how to scale? A lot of the development groups I run into have hundreds or even thousands of developers – and like I said above this generally tends to be an issue only with developers; other groups above tend to be smaller or don't require as broad of a training regimen. So how do we train each and every one of those while still ensuring we deliver products on budget and on schedule? Do we need to train every single developer? Most training classes tend to be spread along the space of a week so how can we afford to take all of our developers off their work tasks for a week? It's not just about the money but about the time as well?

In my experience this is best dealt with by creating a tiered training program. Essentially, for every team (depending obviously on the size of the team) create a new role called a software security architect. This person should become the "go to guy or gal" for anything and everything related to software security.

Once you have this type of a development organization in place, the task if providing training becomes significantly easier. The Software Security Architect is obviously provided with elaborate training and education. This could take the form of one to two weeks of training on security and the development technologies and how the two relate to each other.

The average developer on the other hand can be provided with 4-8 hours of software security awareness that covers the importance of security, security principles, and common mistakes that development teams make and how to avoid them. They don't have to for example attempt to become experts at cryptography or authentication protocols. Anytime they need help with such things they can go up to their Software Security Architect. In fact chances are their Software Security Architect might have built a nice little API for all of these complex security functions.

This tiered program allows you to both achieve a goal of having all of the development staff being trained in software security while also letting you do this and indeed scale across the hundreds or thousands of developers you might have without putting your entire business on hold while the training is being disbursed.

Finally another strategy I have seen successful albeit on a smaller scale is to provide training as part of annual developer summits or geek clubs if your teams already have those. This is a good opportunity to impart training or more likely at least awareness when a large collection of representatives from your development teams happen to be in the same room for perhaps other purposes even.

How to be effective and efficient?

Once the decision to disseminate training has been made, there are a number of things that can be considered to make the entire process both effective and efficient i.e. how do we make sure we are successful both at truly increasing the average knowledge level from a software security perspective as well as do so at the minimal cost. Firstly for the shorter duration classes (4-8 hours) consider self paced computer based training (CBT) classes. Obviously with CBTs, you do gain the advantage of being able to start and stop at any time and incurring minimal cost per student. On the other hand you perhaps lose the hands on experience and interactivity with a live instructor. CBTs therefore work well for training that does not have significant hands on component – for example talking about the fundamental principles of software security or the common mistakes such as avoiding buffer overflows and SQL injection. Live training is much better suited for the intricacies of implementing cryptography or an authentication protocol. You might also prefer live training when your development teams are not too large and are comprised of highly experienced individuals who are likely to have tones of questions.

Another thing to consider is how to position this training. All too often we see companies mandating training in response to a compliance objective and pushing it down to the employees in a similar fashion. Instead it is always better to sell training internally as an investment in the employees. Security is an increasingly popular component of the skill set for developers and thus any formal or informal training they might have on this aspect adds value to their career and helps in its progression. This is especially true for the software security architects. As mentioned in the sidebar it is vital that the person that fills this role be part of the development team and not be supplanted from a security team. Moreover, this role can be made a track in the developer career path wherein senior developers and development leads can fill the role after gaining sufficient development experience with the technologies in use within their teams. This is an excellent way to sell the role to development teams with the carrot rather than the stick approach – the carrot being the tremendous investment in terms of personal training that will be made into this individual.

One aspect of training that is often forgotten is that the training itself can be forgotten! It is therefore vital to have at least yearly refreshers where not only is the material covered again but is also updated to account for the research that came out in the previous year. This is especially important since the world of software security is evolving at a rapid pace wherein problems that were considered purely reliability issues suddenly allow an attacker to remotely exploit them. There is also the opportunity to impart some of the continuous training through the threat modeling and code review processes albeit in an informal manner. By discovering bugs and flaws and discussing how to fix them we are subconsciously training the development teams to avoid them in the future.

If you considering bringing in an outside vendor for training, also consider having them customize their stock classes with examples, references to policies and procedures and contacts for people within your own environments. Ensure that their instructors are developers in the languages that they are going to be teaching. The last thing you want is someone who has never programmed in that language to teach people based on knowledge gained from a textbook. Finally, and along similar lines it is also helpful if the trainer has experience of working with similar enterprise applications as your own.

Finally, another effective strategy is to ensure that at least the security awareness training is part of the developer on boarding process. This means that such training must be integrated with the new hire training and package in general. This ensures that before a new developer even touches any code within their respective development teams they have at the very least gone through the fundamentals of software security.

How to measure success?

As Lord Kelvin once famously said "If you cannot measure it, you cannot improve it." So the question obviously always arises how do we measure the success or effectiveness of our software security training if you will. For that matter that is something that we can ask of any form of training. There are a number of mechanisms I have seen to be useful for this. Perhaps the easiest way is to tie the measurement into the training itself. For example, a quiz or test at the end of the training or perhaps after each module or component of the training. This is the quick and dirty way if you will but multiple choice quizzes are not always the most effective at measuring success – they are more likely measure the memory of the individual than the true understanding of the concepts. Of course you could take this further and make them more detailed assessments where perhaps in a lab format, students have to actually write code that corrects a software security problem in an existing code base.

At perhaps the other extreme is measuring actual improvement on the ground. This is typically a much longer assessment and at first look appears that it would cost a whole lot more besides just the cost of training itself. However, if you think about the assessment not just tied to the training but to the larger software security program, the assessment might not appear to be as heavy. To perform such an assessment, it is important to first create a baseline based on the current state of affairs. Consider performing threat models, code reviews and penetration tests of 5 to 10 of your most critical applications. The results from these security activities will form the current score if you will. Then go through the training program you have chosen to adopt. Don't worry about new individuals joining the team and other such changes too much since they will in reality reflect changes to your team as they would normally occur and hence don't necessarily represent an anomaly. Once the first run of training is completed – perhaps a year to 18 months down the line – run a secondary series of assessments possibly on the next versions of the same applications. If your training and software security program was truly effective you will hopefully see an improvement in the results from your current score from earlier. If you see a slip downward obviously you have a problem and have to question why there was no improvement or indeed negative improvement if you will. On the other hand even if the improvement does not meet your expectation as well you can question which activities are not having the desired effect and why that might be the case.

Hopefully the longish post above will provide you with something useful as you look to create your own software security training program. In fact the more I think about it the more I realize that this will perhaps help in any type of training program. I would also be very interested to hear from you of any other valuable lessons you might have learnt from your own experiences – what worked and what did not for instance. Good luck J.

Why Software Security Must Be Holistic

A few months ago, the software security folks at Microsoft put up a pretty insightful post on security trainings. Over the last few years I have had the opportunity to do a number of security assessments and I must agree that time and again, this fact has been reiterated for me. A lot of organizations and indeed developers make the mistake of thinking software security can be a silver bullet or shiny red easy button if you will. While we would love if that were the sadly, this is not the case. As Edmund Hillary who was the first man to climb Mount Everest, once said "There is no virtue in easy victory". While I don't think software security is that high a mountain to climb but by no means is it a quick fix either. Ultimately it takes a significant amount of time and effort, and really continuous improvement to make sure we are staying at the top of our game and keeping the bad guys out.

Software security is a function of your people, your processes and the technologies involved. Efforts must be made in all of those directions before true "zen" if you will can be achieved. One aspect no doubt about the people is having an informed and trained workforce. This includes your developers but also your testers, your architects, requirements specialists or business analysts, project managers and last but by no means the least your users.

Let me illustrate with an example. All too often when doing application testing we find cross site scripting problems in web applications. Typically, for illustration and documenting evidence we will use something simple like alert('XSS');. The idea being this is proof that the site is vulnerable to cross site scripting. Of course the recommendation goes on to suggest data validation and output filtering and such. Every once in a while when we get the application for retesting – the assumption being all the vulnerabilities (or at least some chosen subset of them) have been fixed – we will see something that shows why just doing security testing (or any one single software security activity) by itself is not enough. We see code that looks like this (in pseudo code):

...

if(input == "<script>alert('XSS');</script>") {

print "Invalid data";

exit;

}

...

 

As a security professional you cannot help but go "Aargh!". But then when you step back and think you realize we are not backing the security testing with training and awareness, policies and processes.

I really think this is where as an industry we have failed. We like selling silver bullets to our customers – "hey buy my product and its all you need" or "buy my services and you will need nothing else". Same goes for things like security industry conferences – there must be more focus on all aspects of software security not just the I found a new security bug or as has been happening more recently – I found an old bug but I am going to give it a new name ;). Of course I know it makes it a harder sell but I think therein lies the challenge. Just like there are many aspects to staying healthy e.g. genetics, food habits, exercise …, similarly with keeping our applications healthy so to speak.

 

P.S. In a future post I will discuss how to setup a software security training program that is both effective and helps keep the costs down by using people's time efficiently.

P.P.S. I plan to expand on the general "Software Security – A Holistic View" on this blog with other aspects that should be critical components of a effective and efficient software security program.

Speaking at SD Best Practices 2007 in Boston

I will be presenting at SD Best Practices 2007 which takes place at the Hynes Convention Center in Boston from September 18th to the 21st. I will be covering a topic close to my heart – being effective at code reviews for security. It should be fun with demos and examples to liven up the discussion. Hope to see you there J.

P.S. Apparently as a speaker I have some ability to get discounted registrations for the conference. So if anyone is interested let me know.

P.P.S. Also presenting at this conference is another of my Foundstone buddies Alex Smolen. If you are interested in securing Model-View-Controller (MVC) architectures then he is your man. This was quite a popular session at SD West this past Spring so would be well worth your time.

The Art of Managing Up – When Sucking Up Isn’t Gonna Cut It!

It seems like the latest trend in blogging seems to be coming up with top 'N' lists of things and not to be left out I decided to come up with my own list. Guy Kawasaki is probably the uncontested leader in this area with his Art of Pitching for instance, Joel on Software and the Art of Interviewing if I can call it that. More recently (and really what I think ended up inspiring this post the most) was Mark Curphey with his Top Ten Tips for Managing Technical Security Folks. Anyways so I sat down to think about what is it that I can write about that would help someone reading this post and perhaps strongly related and more importantly – what is it that I know (or at least I think I know) something insightful about!

So here goes – The Art of Managing Up. A lot of focus during management training is always managing down: how to deal effectively with your staff etc. I haven't come across too much on managing up. In fact I personally think this is one of those skills they should teach you in school and college. In my humble opinion along with your core skills – this can be one of the more important factors that can influence career success both if you're the type who likes to stay at the same job for years together or if you're the job hopper who needs a new challenge every two years or so (if you're the type who likes to jump jobs less than every 2 years and it shows like a trend – I would work on that since that is going to be a huge red flag on your résumé!) Needless to say this post will probably be updated every so often so apologies upfront for the repeated entries that might show up in your RSS reader. I should also apologize upfront about the length of this post but hey I figured there was stuff to be covered and I put some pretty pictures ;).

One caveat that I think is important is that all my experience has been with smallish companies, mature startups if you will so it is possible I think that some of the advice below may not apply in your case, especially if work for a really large company. Also I have always worked in technology so this is really focused on developers (and security consultants J) and the like.

So where am I coming from? Well during career I have had the opportunity to work for a number of different managers and each of them had their own management styles which made them a different beast (no offense J) to deal with. For the most part I was lucky to work for people I really liked working for. I might not have agreed with them 100% of the time but I respected their opinions and I think they respected mine. I have also learnt from all of them and all of my coworkers along the way about what works and what doesn't. Some of the stuff below, I have learnt from my own screw ups, others from seeing people around me. So with that said lets dive into The Art of Managing Up.

First for some prerequisites. Essentially without these it wont matter how well or badly you implement the rest of the advice.

Now for the real meat of this post. Let's call this the framework for managing up ;).

  • Be good at what you do – This might seem obvious but it is really important to be good at whatever it is that you do. You are not going to have much success managing up if you don't have the respect of your manager. Let's face it if you are a programmer you better be among the best in at least your team (if not the entire organization or the industry possibly ;)) if you are going to impress and successfully manage your development manager. This is also the part where you get to hear how you need to work smart and not necessarily work hard. In my experience, people who are good at what they do tend to at least appear that they don't need to work as hard to achieve the same results as the other people in their team. With all of this said though your performance is only part of the equation. As my graduation speaker at CMU so eloquently put it being successful is a combination of performance, image and exposure. And surprise, surprise performance isn't even the most important of three! So the rest of this post really focuses on the other two and attitude in general.

     

  • Listen – don't just hear the boss – This I guess is another cliché of sorts. One thing that I have learnt is that it is always important to read between the lines when the boss says something. This could be in a one-in-one setting or in team meetings. Why is this important? Well very rarely are you going to find a boss that always speaks their mind especially when you or they are new or if they are worried that being blunt might come across as being insensitive. So the trick therefore is to read facial expressions, body mannerisms etc. It's all the stuff they tell you to focus on when you are interviewing someone or going on a first date or dealing with any kind of relationship. Things to watch for expressions like: "Yeah that's great but I think this might be better …" or some other version of that. Well chances are if something else might be better then chances are what you originally did wasn't that great after all. Well don't leave it just at that, first figure out if he / she has a point. Did you really miss some angle? If you don't think so ask the question and make the case for your solution. If on the other hand you agree with the boss then consider the lessons learned from this experience, how can you make sure that next time you do have the truly great solution. Essentially in my experience learning from previous failures, mishaps or even small and seemingly inconsequential mistakes is one of those skills that managers truly appreciate – well the good managers at least J. On a different note, when it comes to listening, try and understand where your manager wants to go strategically and help realize those strategic plans. Often times, they might have a grand vision but possibly may not have formulated all the mini steps it is going to take to get there. Well take the initiative and go beyond the call. Try and see what you can do to help realize their vision. I think it is fair to say that the most successful relationship is one where your personal success makes your manager successful or perhaps it is the other way around. Either way you get the point.

     

  • Under promise and over deliver – Cannot be said enough. Always, always set expectations. This goes way beyond just managing up but with regards to this I have always found that it is best to be conservative in your expectation setting. Essentially if you think you can achieve something in 10 days well say it will take 12. Those extra two days are not meant for you to be slacking off ;) but more for you to look good when you do in fact get done in 10 days. That's the key in your mind this is still a 10 day task. A lot of people in my experience tend to do the opposite, and I am as much guilty of this as the next guy. The temptation is to think that being aggressive in setting expectations will win us the goodie points, problem is that only works fine when we can achieve those expectations. The one time you slip a date, it hurts a lot more with all the times you did make the date put together. Now of course the trick here is to not take this too far i.e. don't set expectations that just seem like your lazy ;). I guess it is something that you learn from experience – what your limits are and how much can you achieve in a given amount of time.

     

    UPDATE (based on input from JD Meier at Microsoft): On a related note it is also important to know what to promise. This is where it is important to understand what is it that makes your boss successful and how can you help to make him / her successful. This is many ways the main mechanism to make sure your manager is going to be happy: something you excel at makes him / her look great before his / her manager. One other thing that JD brought up that I think also falls in this realm and is perhaps not completely clear in the paragraph directly above is that you should not be afraid to pushback at your manager to prevent your plate from over-spilling. It does go back to the under promise and over deliver. It is too late at the end of the project to say "well, I really thought it was too much work and I wish I had told you that at the beginning". Resetting expectations and negotiating and prioritizing tasks with your manager are key aspects of a successful relationship – as long as again you are not doing it to avoid work but to produce higher quality work.

     

  • Over-communicate, always – Most managers I have worked with probably had their biggest irritant as not being "in the know". For better or for worse always over communicate. This includes both times when you are doing well and when you are struggling. For instance, if you are running behind on a schedule, let your manager know early rather than later. This goes back to the under promise and over deliver again. A lot of times we tend to think that we will be able to catch up, but like anyone who has debugged that last, nasty memory leak, sometimes things go wrong and you don't catch up. Guess what you would have been a lot better letting the boss know right the first instance you knew you were slipping. Same thing with good news sometimes, don't wait for this to be your big surprise. Remember this is your boss not your grandparents! If it turns out he / she would have rather had you working on something else again your surprise might work against you.

     

  • Argue like hell but when the decision is made get in the boat and row – This is something one of my first managers used to say. The idea being don't be afraid to speak your mind and argue your point – in fact if you think you will "not get away" with ever disagreeing with your manager perhaps it is time to look for a new job. Now with that said, after the decision is made learn to accept the decision and work to make it successful. Don't be rooting for failure just to prove yourself right even if you are 100% sure you were and are right. In my mind when a team fails, you aren't going to become a superstar by saying "I told you so". If this does happen too often though one might question whether your manager is even open to suggestions and ideas or is this one of those autocratic managers who "never needs to listen" or "always has the best idea" again maybe it is time to move on (see the section about liking something about your boss and mutual respect above).

     

  • Pick your battles – Along similar lines as above, if you are going to put the stake in the ground for something make sure it is a battle worth fighting. And what defines "what is worth" well that's for you to judge. It might be the free drinks being taken away or it could be using a specific technology development platform. If you fight for everything pretty soon no one is going to be asking for your opinion anymore.

     

  • Ask for responsibility, don't wait for it to be given to you or expect it will happen automatically at some point – This one is probably one of the most important in my mind. Again one of my first managers gave me this advice. A lot of times as employees we tend to be shy to ask for more responsibility lest we "speak out of turn" or "step on anyone's toes". The problem though is if you don't ask for more responsibility in my experience no one will give it to you. Sure you will get a tad more responsibility (if at all) each time the annual reviews come around but if you are looking for faster career growth that is probably not going to be fast enough. Now granted there is also some risk with this approach, so you better be good at self assessment – how much responsibility can you take and accomplish successfully so that your boss is left impressed and not disappointed. Ask for only as much as you can take and deliver on it. Then maybe you can ask for more. I think to some extent though you should not be afraid to fail, it tends to make you a bigger risk taker but then risk takers only look good as long as they don't crash and burn ;).

     

  • Don't take anything seriously when the boss is yelling – Let's face it we have probably worked at least someone who is a screamer ;). Typical scenario is they are having a not so great day – perhaps their boss is leaning on them too hard. Anyways you go in to get something reviewed and they find the smallest of issues and begin to yell, insults and the like. What I have learnt is people usually don't mean all of what they say when they are throwing an anger fit. In fact more often than not they are in fact explicitly looking to be hurtful just to make their point! I believe the best thing to do in these situations is to duck for cover at the earliest possible moment i.e. just keep quiet, keep your cool and get out of the firing line as soon as possible. Don't take anything that was just said to heart but wait for a day or so and then go back in to have a chat and present your point. Before doing that though sanity check your argument or whatever it is you were presenting with a co-worker who will give you an honest opinion. If you believe you were just the victim of collateral damage then by all means attempt again when heads are cooler. The main thing though is to never let someone in such a position either bully you or make you feel real bad or insulted. Needless to say if this happens way too often then maybe you should be looking for a different boss and leave him / her with a free voucher for anger management classes on your way out ;).

     

  • Don't burn your bridges – At many points in this post I have (sometimes half jokingly) suggested it might be time to move on. The fact is at some point the time might come for you to look for greener pastures. When this does happen make sure you handle it as best possible. Be flexible with your exit plans and don't leave in a huff or with a pile of unfinished work left behind for someone else to cleanup. Avoid also any nasty arguments with either your coworkers or your boss. It is common to assume that "hey I don't have to work with them anymore I might as well give them a piece of my mind". In my experience no matter how bad they were it is probably best to not burn any bridges. Hey you never know when you might have to come back to them or need a reference from your ex-manager or (and it has been known to happen) six months after you leave company X to join company Y, company Y hires your ex-manager from company X and suddenly he is your manager or perhaps your manager's manager again.

     

  • Don't compete with your coworkers – To be quite honest I wasn't too sure about putting this one in. I think in life you are always competing with people around you. The aim though is to keep that competition healthy. Bottom line is try to work hard and make yourself look good rather than spending your effort making the other guy look bad. Why is this important from a managing up perspective? Well it is because the best managers I have had the opportunity to work with have immediately since this for what it is and you end up doing yourself a disservice more than anything. Let's just say it's kind of karmic thing. You can bet that if you are spending time trying to throw your coworkers under the boss before your boss they are spending at least the same amount of time if not more doing the same to here. And no matter how good you guys are at your jobs, the fact is that is not a conducive environment for the best productivity so give it a rest and let everyone's skills and work do the talking!

     

    UPDATE (based on input from JD Meier at Microsoft): Turns out sometimes you might have to compete with your co-workers, for instance, during the brain storming phase of a project where people might present many different ideas of which one will be selected or if you are competing for budget or resources. In such cases certainly put you best foot forward. But again once the decision is made like I said above get in the boat and row. Verbatim from JD since I could not say it any better: "At the same time, be a mentor and team player for your team mates. It's a better long-term strategy than trying to out-do. As far as true competitiveness -- internalize your bar. Make sure you are constantly becoming a better you … a little bit at a time. The little bit adds up. It's how John Wooden built the winningest basketball team. He made each player focus on their own improvements." I think his last point is especially key – always compete with yourself.

Footnotes: One of the best classes I took at CMU was Organizational Power and Politics. A lot of the learning I did there was relevant in a very real way in my daily life and in my career. Some useful reading that came out of there was the work of Robert Cialdini. If you haven't read his books on influence you should. Another interesting learning was the Stanford Prison Experiment and of course what class in politics is complete without a reading of The Prince. The course text was also great which was by Jeffrey Pfeffer - Managing With Power: Politics and Influence in Organizations, another must read.

TechEd 2007

My Virtual TechEd conversation with Mike Howard just went up on the Virtual TechEd site. Come watch a couple of software security practitioners chat about the state of the industry and where we go from here.

Some of the key things we talk about include how to sell security internally in your organization, what to expect in terms of overheads when you do integrate security into the SDLC. All in all pretty interesting IMHO.

Silverlight Beta

Silverlight Beta
Installation and Setup

This is my first dabble in Silverlight too - embedding this video was pretty cool using Expression Media Encoder and the instructions here. If you dont have Sliverlight installed you probably just get a dummy screenshot above so follow the Silverlight links above to get to the video.

Patch Tuesday Blues

Today my friends is Patch Tuesday and like any good security professional (J) I went up to Microsoft Update to get my monthly dose of patches. 9 of them installed fine however one just would not install despite repeated tries. Specifically this was Security Update for Microsoft .NET Framework, Version 1.1 Service Pack 1 (KB928366). The same update applied to my .NET 2.0 installation without any trouble but with .NET 1.1 I was consistently getting this error in the Microsoft Update History.

Anyways I proceeded to manually download the hotfix using the link for Windows Service Pack 2 and .NET 1.1 Service Pack 1. Now when I proceeded to run this hotfix, it prompted me for the file netfx.msi which it couldn't find. Now netfx.msi is actually part of the original .NET install but gets deleted when the install completes successfully. So to get a hold of it I went back to the Microsoft website and downloaded the .NET 1.1 Service Pack 1 installer – only problem is this file is called dotnetfx.exe. Well contained within it though is netfx.msi, so all I had to do was extract netfx.msi out using the following command "dotnetfx.exe /t:c:\temp /c" and then point the waiting hotfix installer to the recently extract netfx.msi. In a couple of seconds the installation completes and I am fully patched waiting for the next Patch Tuesday J.

If anyone runs into this issue, hopefully this will help you.

UPDATE: Since I posted this I have received well over 100 responses, some thanking me and others asking for help with other errors. Unfortunately I am not going to be able to figure out every error message out. Bear in mind that Microsoft does provide free support for any security updates related issues so this might be an opportunity to take them up on that.

 

Security Threat Level Down to Fuchsia?

Last few trips I have flown I noticed the airlines (multiple) have started using metal silverware again – so metal knives etc? Did I miss some memo about the little knife on board not being a security threat no more? :P

 

P.S. Or did it dawn on the wise ones that seemingly make these rules that this security theatre was not really making anyone more secure?

MindMapper vs. MindManager

Thanks to JD Meier at Microsoft I have become a huge fan of mind mapping in the last few years. When JD first introduced Mark Curphey and myself to this, I have to admit I wasn't on board immediately. It was a little too "new age" for me. So I went about 6 months down the road before I had the inclination to use it again. But then as a bunch of people at work will testify I had drunk the kool-aid. I was using mind mapping for everything from building threat models and doing code reviews to working out my articles and presentations. I even convinced Foundstone to purchase a bunch of licenses of MindMapper as a lot of other people at Foundstone had become fans as well. Why MindMapper – well that was what JD was using and what another friend from back at CMU was using as well. Anyways about three years went by and I continue to be a big fan, to the point where I was accused of owning stock in MindMapper since I was evangelizing it so much J.

In March this year I was at the MVP summit in Seattle and met JD on the sidelines. We were chatting about a bunch of things and mind mapping came up again. Turns out JD has been using MindManager more recently. One benefit of being an MVP is I often get sent review copies of books / software etc and consequently I know have a free copy of MindManager. While I don't have a final verdict on which one of the two mind mapping software is better I do have some initial thoughts. One of the things I love about MindMapper is the fact that you can easily work on your mind map using just your keyboard. Hit enter to edit a topic, type "over" a topic to add a new child topic and use the arrow keys to navigate in between. MindManager on the other hand (and the little I have seen of it I must admit) has support for the tablet pc and ink as well as in general seems to have a richer overall user interface (ribbon etc). Also there seem to be newer versions of MindManager a lot more often than MindMapper and in my feeble mind that is an indication of some sort at least of innovation. Off course one challenge I would have moving from one product to another is that there is no easy way to export from MindMapper (in which I have a ton of threat models – and I do mean a ton – I did a search for file types on my drive and as it turns out I have more twd MindMapper files than Word .doc files) to MindManager. I ran into this post though and decided to take on the author's challenge. Turns out it wasn't hard at all and in my limited testing it seems to work reasonably well. If anyone wants to try it out here is the process:

  1. Save the following code as mmconvert.xslt

 

<?xml version="1.0" encoding="UTF-8"?>

<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:fn="http://www.w3.org/2005/02/xpath-functions" xmlns:xdt="http://www.w3.org/2005/02/xpath-datatypes" xmlns:ap="http://schemas.mindjet.com/MindManager/Application/2003" xmlns:cor="http://schemas.mindjet.com/MindManager/Core/2003">

    <xsl:output version="1.0" encoding="UTF-8" indent="no" omit-xml-declaration="no" media-type="text/html"/>

    <xsl:template name="processItem">

        <ap:Topic>

            <xsl:if test="item">

                <ap:SubTopics>

                    <xsl:for-each select="item">

                        <xsl:call-template name="processItem"/>

                    </xsl:for-each>

                </ap:SubTopics>

            </xsl:if>

            <xsl:variable name="topicTitle" select="title"/>

            <ap:Text PlainText="{$topicTitle}" ReadOnly="false">

                <ap:Font/>

            </ap:Text>

        </ap:Topic>

    </xsl:template>

    <xsl:template match="MindMapper/item">

        <ap:Map>

            <ap:OneTopic>

                <xsl:call-template name="processItem"/>

            </ap:OneTopic>

        </ap:Map>

    </xsl:template>

</xsl:stylesheet>

 

  1. Export your current mind map from MindMapper as XML
  2. Use some XSL transformation engine such as the one in XMLSpy to apply the above stylesheet to the XML file you got from MindMapper
  3. Open the XML file now obtained in step 3 (i.e. after the XSL transformation) in MindManager and voila you should have yourself a nice little MindManager mind map!

Bugs and feedback through the comments field pleaseJ.

Administrivia: Wiki updated!

New articles I have been working on in the last few months:

More Posts Next page »