Posts Tagged ‘Consulting’

Help talking to the non-security professionals

January 18th, 2009 by

Recently, I have been spending a lot of my time working with clients on SDL (Security Development Lifecycle). This is a new trend in the security industry and a welcome development in my opinion. In doing this SDL work, I spend a lot of my time working with developers, testers, and PMs who are not security professionals. Discussing concepts like threat modeling, fuzz testing, response planning, and even security training they can easily get overwhelmed with all the complexity the SDL and computer security in general can entail.

I have found a few techniques that I would like to share to help smooth communication and help the professionals and non- profesionals to get their respective jobs done.

  1. Talk slow. This one should be self evident. Discussing subject matter that is new or confusing to someone is only made more difficult if you talk fast. Listeners have no time to process the new ideas and are instead just trying to keep up.
  2. Be a dictionary. Computer Security contains a vast array of concepts and domain specific jargon. In security it is often difficult to adjust terminology to an audience, so instead, try to gauge the audience and go back and explain or define the words, acronyms, or concepts that they may not be familiar with. The critical point here is to do it immediately after use rather than waiting until the end of the conversation. By that point, it is usually too late and the definition may not be properly associated with the item.
  3. Ask questions. It is very important that you are constantly gauging your audiences comprehension. This does not mean using the Socratic method to lead them in their own exploration of ideas, but rather inquiry for the purposes of confirming that you have successfully conveyed meaning to them. Remember, that in almost all cases, incomprehension on their part is a failure on yours. Questions help to highlight to listeners what elements of the discussion you, yourself, consider important. Also, try asking questions from different angles. Asking oblique or tangentially related things can often spur a better understanding in the audience, just make sure it is not something that would appear out of left field to them.
  4. Do not accept nods. Similar to #3, you need to be able to tell when people really understand and can follow what you are saying. I have found many times when a person would nod as I explained a specific security concept to them or spit back the exact language I used, but when I try to get them to describe the implications or rephrase in their own words, it is evident that they are still confused.
  5. Reiterate. Repetition can be critical to ensuring that concepts "sink in". Note, though, that I used the word reiterate. The reason for this is that you should change the way you say it and words you use when repeating the concept or idea. This can be one of the trickiest techniques, because it is easy to over do it and cause more harm than help. I find it works best when sprinkled into a long conversation, especially if the conversation keeps getting sidetracked by definitions, clarifications, or completely external items.
  6. Make lists. This is probably the favorite for most PMs out there. PMs love lists. There is nothing they want more than to break all this complicated, confusing security stuff into small, easily managable chunks. Lists also help people to take notes by calling out concepts that can be grouped or ordered together. A list of bullet points (even in a conversation) are usually more important than the text before or after. I am not and have never really been a PM, but I think this is part of he genius that makes a good PM. PMs usually have too many things to do and items to keep track of, the only way they can handle it all is to be insanely organized and maintain lists. Helping them or any other detail oriented note taker to do this makes your job easier as much as it does theirs. 
  7. Clarify language. This is similar to #2, but is targeted at the way you discuss things rather that words you may use. Make sure relationsips between things are explicitly called out (ex. First a, second b rather than this…then that). Use active rather than passive forms of verbs and try to minimize wishy washy or otherwise indecisive language. Avoid implications, exaggerations, and make clear when somethin is a WAG (wild assed guess). This can be very challenging for people to do during a spoken conversation so I usually recommend you start by practicing over e-mail. Being careful and spending time picking out the right words and phrasing can double or triple the amount of time it takes to write an e-mail, however in the long run, the amount of time saved due to fewer misunderstandings and resulting errors will make it worth it.
  8. Anticipate. Finally, try to think ahead. As a security professional, you know the processes and outcomes far better that the people you are working with do. Try to divine what might confuse, hinder, or block the people you are working with and try to provide them answers or solutions before the need them. Remember that in most cases you are not a teacher and they are not working with you to learn by trial and error. Sending them off with a hint and letting them waste time trying to discover things on their own is not how tehy should be handled. Instead, inform them, point them at learning resources, or provide a solution and spend time explaining the reasoning behind it. Do you have any that I have missed?

Tags:
Posted in SDL | No Comments »

It all comes back to the basics

April 29th, 2008 by

Recently there has been a lot of talk in the security community about the Flash ActionScript exploit written by Mark Dowd (http://documents.iss.net/whitepapers/IBM_X-Force_WP_final.pdf). I will not go into a breakdown of the exploit as others have already done a great job of blogging about it. What I would like to discuss is two big takeaways that even programmers who are not "uber-hackers" can appreciate.

The first takeaway is the importance of understanding and implementing the fundamentals. The exploit above occurs because of a NULL dereference triggered by an out of memory return by malloc(). I remember in my first C programming class when I was working with a partner an a project and he was trying to properly implement malloc(). I had already been using C for a few years and always checked the return of a function. I could not figure out why he was not checking to make sure sufficient memory had been allocated. He gave me the excuse that it would require a lot of code to check the return value and that since the data structure was small the allocation would fail. Nonsense, as I demonstrated by filling up the 640K of standard memory. He then argued that we would be better off implementing XMS or EMS to access the other 3MB of "high" memory, a silly argument if ever there was one.

When non-security professionals describe what hackers do they often say that hackers look for ways to bypass restrictions and go around roadblocks. This is a somewhat fair description, but what they may not know is that often hackers are merely taking advantage of mistakes or the faulty reasoning of programmers who tried to skip or work around something simple or basic that they felt would be too much work to implement properly. The original "hacks" were simply ways of getting things done quicker, easier, or more elegantly but sometimes there is a fundamental reason for doing things one way and the "hack" just gets you into hot water. Anyone who has ever picked up a C programming book and looked at the function info for malloc() knows that it is NOT guaranteed to return the memory requested. Obviously, it is a BAD idea to simply assume that it succeeded in allocating all the memory requested. Know your functions/methods and how to properly implement them.

The second takeaway for the average programmer is the need to integrate and leverage the latest in security functionality in your code from the ground up. What do I mean by this? Follow-up research on the exploit has shown that if DEP had been turned on and opted-in the exploit would not have worked. DEP marks portions of memory as NX (No Execute). Such areas in memory will trigger a processor fault if an attacker attempts to execute shellcode they have somehow loaded into such memory. Is DEP a panacea- No. But it provides a second layer of defense. Now you might say- DEP is a system setting that users or admins or Microsoft can turn on or off, there is nothing I can do as a programmer. This is not true. First of all, you need to write your application to make sure it works properly with DEP turned on. You need to test your application to verify this. You need to inform users so they know they can safely use DEP with your application.

A number of other features like ASLR (Address space layout randomization), /GS (canary based buffer overflow detection), etc. are provided now by Visual Studio and other compilers or by the latest versions of the Windows operating system. Developers should be building their code to use these basic security tools that are in most cases so easily integrated. None of these features can prevent all security threats, but there are many applications out there using outdated compilers or failing to implementeven the simplest of automated defenses for lack of awareness or a fear of performance degradation. To the former- browse through just a few of the numerous security respurce out there and then review your compiler/linkers security related flags; to the latter- given the massive code bloat in this object oriented development world compared with the (good) old days of hand tuned assembly in a COM file what is a one or two percent more overhead :) .

Tags:
Posted in Development, SDL | No Comments »