September 29, 2005

Is Skype getting to big for its own good?

I like Skype. Works awesome on my desktop and my tablet. Heck, with my bluetooth headset I can walk around and have conversations, sometimes with BETTER quality then the land line for some of my overseas contacts.

I have been a long time user of the product, and a customer since last summer (that's right I bought in for the voicemail). All before the hype of Skype. But recently I am starting to see the downside of such a growing business.

Their growing pains are starting to affect me in a negative way. I have support instances logged now that are now two weeks old without resolution. I get answers that include text like:

Unfortunately we have not been able to get to your request for Technical Support in a timely manner and we apologize for this. We try and get to as many requests as possible but due to the high number of requests and the fact that many of these problems are either irreproducible problems specific to your computer setup or already answered on website we cannot always answer every specific request.
We suggest that you search our Help section knowledgebases, user guides and troubleshooter for answers to your technical problems.

Right now, I am paying for a voicemail service that doesn't work. Used to. No idea what changed. And moving to their latest version (1.4.0.71 as of this writing), doesn't seem to resolve it. But now I have had 4 people text or email me and tell me they would have left voicemail, but that it never went to the voicemail. And to boot, even though "My Account" on skype.com says I have 9 months left of voicemail, my Skype client tells me I have less than a week! *sigh*

I really wanted Skype to be MY communications medium. Unfortunately, I cannot rely or trust that it will work for business communications. Heck, they can't even get it straight that I still have 9 months left on my account!

Perhaps they are growing way to fast for their own good.

Posted by SilverStr at 09:30 AM | Comments (4) | TrackBack

September 23, 2005

Visualizing Hostile Code in 3D

Now this is just trippy. F-Secure has an awesome 3D visualization movie showing the structure and execution of the W32/Bagle.AG@mm worm.

This is a wicked way of looking at how malware runs on a system. It would be interesting to see the scripts they mention on their blog that put the IDA stuff through Blender. So now when your grandma askes what a worm looks like... you can show them :)

Neat stuff. Great job guys.

Posted by SilverStr at 03:16 PM | Comments (1) | TrackBack

September 15, 2005

User Account Protection (UAP) in Vista: Did Microsoft get it right?

I wasn't able to make it to this years PDC, but I have been lucky enough to get my hands on some of the security slide decks. One slidedeck that was of REAL interest to me was on how to secure your applications with least privilege that was being done by Steve Hiskey.

I was just floored as I read through it. LUA has come a LONG way since the pre-release of Longhorn that I have been running. And now that its been renamed to UAP (LUA=UAP), I am starting to get a better picture on how Vista is going to handle this. The biggest thing I learned that has changed in Vista? Well it would HAVE to be:

All applications run by DEFAULT in standard mode unless the manifest requests admin rights, or the app is in the app compat database. EVEN WHEN RAN AS ADMINISTRATOR

That's right, even when logged into the administrator account, apps will start up in standard mode (meaning without elevated privileges). If you need admin perms, then you can select "Run Elevated" to do so. In many cases, it will prompt you to do so.

This is more clearly shown in the following dialog:

If you will notice, the disk cleanup wizard prompts even the administrator that they need to increase privileges. For you Unix geeks out there, think of this as the right way to implement sudo. I even think this method is easier than how Apple did it with OSX. No weird grace period that lets everything run elevated. Associate risk appropriately through each app!

Congratulations Microsoft. You might have just done this one right. Guess its time to install the new CTP bits of Vista and take it for a whirl and see how well it works.

Posted by SilverStr at 04:22 PM | Comments (8) | TrackBack

Book Review - 19 Deadly Sins of Software Security

Back in July I posted that I couldn't wait to get my hands on a copy of "The 19 Deadly Sins of Software Security". The authors (Michael Howard, David LeBlanc and John Viega) have contributed to some of my favorite writings, and I just knew it had to be a good book.

It might be because I have read so many of their other books, that I didn't find this book as appealing to me. That's right, I didn't really enjoy this one. I am guessing its because I was spoiled by already reading Writing Secure Code, Secure Programming Cookbook, Building Secure Software etc. that I just didn't feel I got as much out of the book as I wanted.

More importantly, I think the guys missed a great opportunity. The format was excellent:

  • Overview of each Sin
  • Show which languages are effected
  • Explain the Sin
  • Show the Sin in various langauges
  • Show how to spot the Sin pattern during code review
  • Show testing techniques to find the Sin (when possible)
  • Show real world examples of the Sin
  • Show redemption steps

But while the format was great and to the point (which made for a more streamlined read) it was the last step that I was expecting more out of. Especially since "...and How to Fix Them" was in the title. This was the best place to REALLY show how to fix sinful code. As an example, in the Integer Overflow Sin they go into detail to show how a senior developer with lots of experience had a function checking for an overflow that was flawed. Near the end of the page they even show how to fix it. What they could have done was bring it full circle and rewrite the function showing the right way to do it, and then providing the "correct code" in the various languages. I was expecting that throughout the book, to no avail.

This is what I think is missing in all these books. I want a SHORT book I can give to a new developer joining the team so they can see how to write safe code correctly, even to the point they can almost cut-and-paste some of these techniques into their own code.

For a new developer coming in to secure software programming, I am not sure that this is the right book for them. It misses the background to explain WHY its such a problem. Writing Secure Code and Building Secure Systems were two books I rather enjoyed because of all the back story about it. And that made for a more enjoyable technical read of those books. However,I just felt this book was too dry as they tried to balance depth with bredth in 270 pages.

With that said, I think this would be a PERFECT book for a developer who wants a quick and dirty understanding of the Sins and how to fix them without really understanding WHY, and how deep the risks can go. More importantly, I think this is a good intro for code auditors and whitebox testers who don't have to have as much coding experience to know what to look for (at least in a first pass)

I am assuming that if I hadn't read the other books that I might have more enjoyed this one. It is jammed full of good technical information, but just didn't "turn my crank" so to speak compared to their other works. If you have read the other books, I am not sure how much more you would gain from this one.

What WOULD be interesting is if someone new to this read this book first and THEN read the other ones. I would bet it would be an eye opening experience as you dug deeper into "Alice's hole"... so to speak.

Posted by SilverStr at 02:21 PM | Comments (1) | TrackBack

September 13, 2005

Is SBS 2003 secure or not?

So I had a few people email me who attended SMB Nation who wanted to know if SBS 2003 was secure or not. They are worried that the fact that my hardening kit found so many items to recommend changes for, that maybe SBS isn't as secure as it should be.

I think I should debunk that kind of worry here and now.

Absolute security is a myth. With enough time and money an adversary can find a way to access a system. ANY system. ANY operating system. You should read the 10 Immutable Laws of Security to get an idea of just some of the ways an adversary can gain access.

But here is the reality. Any operating system can be made secure. Just as any operating system can be made INSECURE. It's all about how it's configured. Commercial operating system vendors have to weigh security defaults against usage of the system for the masses... the customers purchasing their OS. Traditionally (aka the past) that has been shown to be riddled with insecure practices in an effort to make the system work easier for the user, sacrificing security.

But SBS is different. Wait. That's not right. SBS gets the BENEFIT of being different because Microsoft changed their thinking on this for all their current operating systems. Windows Server 2003 (the core under SBS) was radically redesigned using Microsoft's secure programming SD3 principles. If you don't know what those are, it boils down to:

  • Secure by Design
  • Secure by Default
  • Secure in Deployment

SBS 2003 is much more secure than it previous versions. The attack surface of the system is considerably lessened with the approach Microsoft took in turning off services that are not needed. Most code has now went through special security dev tools like prefast, App Verifier and FxCop that help find problem areas in drivers and applications. Huge code audits occured before it's release, and we can see that impact on the rather small amount of bulletins that have been released on the platform, compared to its predecessors. The default settings are acceptable against the TYPICAL configuration of an SBS network, as determined by Microsoft. You CAN make parts of it more secure. But it is a rather secure platform to begin with.

My reason for hardening SBS 2003 isn't because I think the core OS is insecure. I am actually impressed with the Srv03 OS core and don't worry that much about it. The reason I harden SBS 2003 is because I am uncomfortable in having my web server, database server, mail server and DC on a single system... and want to do EVERYTHING I can to tighten the reigns on the system. Especially when you are exposing those application services on the network. Many hardening suggestions are security best practices. Some people may or may not agree with those settings. But that's the reason for individual hardening. It brings risks down to acceptable levels for ME. You may or may not associate the same risks as I do. That is your judgement call.

So is SBS 2003 secure? Sure is... for most people. But not enough for me. I regularly have script kiddies bombarding my servers. They rather enjoy it. After all, trying to crack my servers seems to make them feel 'leet. (God I wish they would go away). Only you can decide what is acceptable risk to you. I can't make that call for you. If you have the same concerns with having so many services on a single machine, download all the hardening guides I recommended at SMB Nation (the PPT with all the links are on your USB key) and spend a couple of days reading all the docs. (Its around 600 pages) It will explain how to harden those pieces, and you can decide what you want to secure further.

Good luck!

Posted by SilverStr at 12:04 AM | Comments (2) | TrackBack

September 12, 2005

The Weakest Factor is STILL the Human Factor in Security

At SMB Nation I was re-enforced with the notion that human nature will trump security best practices time and time again. While sitting in the hallway in the Microsoft Conference Center with Susan Bradley, preparing for our talk on securing Small Business Server, I was using her TabletPC to make a change to a slide.

I was explaining to her the fastest way to show that someone is TYPICALLY running with least privilege is by clicking on the time/date control on the task bar. You will only be able to get the "change" dialog if you have those privileges (which typically only admin accounts have). As I was saying this, and expecting the double click to fail... up pops the dialog.

What the...

Susan doesn't run with least privilege on her own machine!!!!! Will wonders ever cease??? The diva that runs so many posts on least privilege does not herself do it on her TabletPC. Her reasoning? Because she is lazy. That shocked me. It shows how even those who KNOW about least privilege don't always use it. As I dug deeper, what she seemed to really mean was she felt the risks weren't that great because she doesn't connect it to a domain, and some currently configured apps would be difficult to reset (ie: Thunderbird, installed with an admin profile). I then asked the next logical question... "do you even let it touch the corporate network"? When she said "yes"... I said that's it... its all over. Domain or not... she is a conduit of potential risk to her corporation.

Then our presentation started. We entered the Kodiak room and started with all the introductions. Then Susan, willing to admit her mistake, told me to "out her" on stage. And then everyone had a laugh at her expense. It came close... I almost picked up the "Susan 2x4"... but then I reflected a bit deeper. This could have been me. It could have been you. It could be anybody.

What can we learn here? Well first off, I think this incident shows how the need for an easy to use LUA in Windows Vista has never been more prevailant. The fact Susan was running as admin because it was to cumbersome to change it is inexcusable. We all know that Susan, as both a SBS and Security MVP, GETS what has to be done. But in her focus to get her work done day to day... humanity trumped best practices.

Secondly, I think this shows how layered security on ALL hosts on a network has to be considered... especially with ingress and egress filters. Her TabletPC was a conduit of potential risk. She had it on vile network backbones while in Vegas, and then went and plugged that into her corporate network. Who knows what she could have brought along with her. Ensuring that machine has NO privileges to touch anything on the corporate net could mitigate against this risk.

And finally, it was a wake up call. As security professionals we cannot just TALK THE TALK. We have to WALK THE WALK.

So Susan, here is my challenge to you. IMMEDIATELY create a new limited account on your TabletPC called "Bonehead". Then create a shortcut on the desktop, point it to Thunderbird and set it up to run with the credentials of your "Susan" administrator. It is a short term fix for everything else until you can properly reinstall Thunderbird and move your mail spool over. At the same time, it will reduce the other risks you expose to yourself by making the rest of the system run with least privilege. Then, I want you to read this article by a fellow MVP and convert your bloody harddisk to NTFS. Get rid of that FAT32 crap.

Fix your TabletPC before you plug it into another network. You know better. You have two weeks before the MVP summit. You're lucky I won't be there to check on you. Maybe a fellow MVP can do that for me :)

Posted by SilverStr at 10:44 PM | TrackBack

September 10, 2005

How to spew coffee on your laptop while at a conference...

Read this...


Posted by SilverStr at 09:13 AM | TrackBack

September 09, 2005

Sharepoint + InfoPath = WOW

DAMN YOU CHAD! I don't have enough time in the day to keep up with learning sharepoint as it is. Then you go and impress me in your presentation at SMB Nation on using InfoPath forms to post to Sharepoint.

In combination with web services, I can see how my own organization could use that as part of our onsite data asset risk assessment process with clients. Currently we use a paper form, and then input things manually. I wasn't looking forward to writing a web site to handle this sort of thing in the future as we refine the process. Now I know I can build an InfoPath form and have onsite personel fill it in, sign it with ink, and then submit it to our Sharepoint Intranet. Yes thats right, the InfoPath forms are Ink-aware! We can then query that data and generate reports as needed.

Man that's awesome. I hope I can figure out how to write Sharepoint extensions to generate a "dashboard" report for our assessment process. Now if Microsoft could just fix the stupid security model in Sharepoint on SBS... tie it to the damn security groups already!!!

Posted by SilverStr at 04:38 PM | Comments (2) | TrackBack

SMB Nation - Day 0.5

Made it to SMB Nation. As I was already pre-registered and received my kit yesterday when I arrived, I got to skip the registration line. That was a good thing (sorry Martha), since I was pretty much the last person off the bus and would have probably been in line for some time.

The morning keynote was excellent. I actually learned a bit more about market opportunities Microsoft that views, and got some insight into some of the programs Microsoft is engaging for its partners. I also saw an interesting demo on Microsoft's accounting program, and the strong integration with other Microsoft technology. One point of contention... it appears that Canada's roll out strategy for MS products in the small business space seems to be lacking. They keep talking about US roll out, and UK roll out, and brushed off a few questions about Canada as things to worry about in the future. Maybe it's Canadian pride, but it seems kinda silly since we are on the same bloody continent speaking the same language. I don't see why it's such a problem to roll it out. I guess economic scale comes to play here... who knows.

After the keynote I walked the Vendor tradefloor. It was insane. I couldn't talk to a single vendor as it was so busy as people tried to get swag. No worries... there are a couple of more breaks and I should be able to have some one on one's with them then.

The first session I went to was on "Tripling the Value of Your Consulting Firm in 7 Steps". Amazingly enough, it was basically a merging of thinking of the MacKenzie's 7 S's and the E-Myth mentality of system based workflow processes, peppered with measuring success through a balanced scorecard. Been a while since I saw someone else talk about Critical Success Factors. But it was awesome, since I am passionate about building business in this way.

I really liked the presentation style of Dan Fine from Fine Business Solutions. He was entertaining, very informative and knew how to place humor in his slide deck. Tom Poole... not so much. He was well versed on the content, but I just wasn't engaged in what he presented. Together though, they balanced each other nicely and overall it was a great presentation. Good information and well worth investing in looking at the slidedeck (assuming you have a copy. I don't believe it's public and therefore will not link to it here)

Lunch was a good networking opportunity. Met some interesting system integrators and VARs and talked mostly about bluetooth insecurities. Have to remember to stay on track and learn more about them, instead of answering their questions about security :)

Right now I am sitting in a session about CRM. Quite frankly this wasn't the presentation I was hoping for. Hence why I have time to blog. I mistakenly thought I might see how small businesses could LEVERAGE Microsoft's CRM to be more productive. You know, use CRM as a user. Unfortunately its about how to SELL CRM to customers. And to me, it isn't really that engaging. To be fair, there is lots of information... it is just irrelevant to me. My fault for not reading the description better. Some day, someone will have to show me how CRM could help my small business. That's a challenge for any CRM reseller at the conference. Pull me to the side and show me how YOU use CRM in your own business. If you don't actually use CRM, then don't bother trying to sell me. If you can't leverage it yourself, how can you expect me to?

Anyways, I should get back to listening to the presentation's Q&A session. I may still learn something if I pay more attention. So far the conference has been good. Lots of good networking opportunities. Lots of intelligent conversations. And some good presentations. Even the CRM one... assuming you want to sell CRM.

Posted by SilverStr at 01:58 PM | Comments (1) | TrackBack

SMB Nation - Day 0

So I made it to Redmond near dinner and enjoyed walking around Redmond Town Centre. What a kewl place. Lots of good stores, some great food and interesting people.

When I was done my 'walk about' I headed to the Marriot's bar, drank some great gwertztraminer (although insanely expensive) and caught up on some reading on 19 Deadly Sins of Software Security. Sometime around 10 I switched to beer and shortly after met up with Susan who had got in later in the evening. She ran around and introduced me to some great SBSers, and then I headed to bed.

When I got to my room I thought about jacking into the wireless. At one point I thought I might just attach onto 'The Diva Network', but they didn't set it up yet. I started to think about paying for hotel access, and then noticed that the access point was actually IN MY ROOM. Note to whomever runs the hotel net.... NEVER PUT THE COMPELTE IP information on the bloody device, and leave a management port open. Worse yet, don't leave a cross over cable to plug in with, hanging in the closet! :)

Then my ethics kicked in. I decided to play nice and not use that information to manually plug in and get a working MAC addr to use. In case you don't know... it IS quite easy to sniff a wireless net, get a working MAC addr and reprogram yours so you can get access to the net. Alas, I won't explain anything more past that. However, I will say having access to the access point like this is not always a good idea.

I think I will head to bed and get up early for the conference tomorrow (erhh... today).

Posted by SilverStr at 01:23 AM | TrackBack

September 05, 2005

Spam Protection for Small Business Server

If you are an SBSer, you know the power of having an enterprise mail server like Exchange at your finger tips. You also know how difficult it is to tweak to deal with the boat load of spam that's out there. Yes, there are enterprise antispam solutions.... but very few are at an SBS price point.

I have been looking at solutions for our office for some time now. First I tried using Sean Daniel's recommendations in his article on layered spam protection. For some reason, I wasn't seeing anything being blocked. I think Spamcop might just be a bit out of date, and the Exchange Intelligent Message Filter isn't doing much for me.

I then tried GFI's MailEssentials for Exchange/SMTP, but quite frankly it didn't do ANYTHING. I couldn't tell if it was working at all past it saying it processed emails... yet blocked nothing. I was so hoping it would work because it can move stuff into the user's "Junk" folder, which was something I really liked. After 3 calls to their support and a boat load of emails to a Canadian sales rep I gave up and uninstalled it.

Then over the weekend I installed ORF Enterprise Edition 2.1 from Vamsoft. Their Open Relay Filter software was amazingly simple to set up and configure on my SBS box. They had an excellent step-by-step help guide to assist in configuring it (something GFI totally missed), and I was up and running in less than 15 minutes. And within 24 hours it was not only filtering email, I was able to determine that 57% of the email that came in was spam! Yep, that's right... I found a tool that works great for SBS. And the kicker.... an SBS price of $198 for the server license.

To be fair, ORF hasn't eliminated all the spam. I have had a few get through in the last 24 hours. But the fact that it stopped 57% of the crap coming in with NO false positives... I am still very happy with the results. Vamsoft offers a 30 day trial (which is what I am using right now), and if you need spam protection, you might want to check this out. I am going to keep it going for the next month and see how well it does, especially with false positives. By the looks of things... it will work out perfectly for our needs.

Posted by SilverStr at 01:24 PM | Comments (11) | TrackBack

September 04, 2005

SMB Nation is just around the corner!

Man SMB Nation is almost upon us. Less than a week away before I am on Microsoft's campus again.

For those that don't know, Susan and I are slotted to speak on September 10th from 3:00 till 4:15 on the topic of "How secure is your SBS 2003 Server?". We will be doing a point/counterpoint on security on SBS and how it can be made safe to meet security objectives. I will be ranting about how to harden Small Business Server and how to perform threat modeling on the SBS net, while Susan will undoubtedly go after patch management and compliancy issues. You can check out the rest of the schedule here.

I will be arriving in Seattle in the ealy afternoon on Thursday (I believe sometime around 3pm). For all the SBSers out there that are staying at the Marriott Hotels at Redmond Town Center, drop me a line if you want to get together before the conference starts.

No reason we can't start the party early!!!!

Posted by SilverStr at 08:59 AM | TrackBack

September 01, 2005

High Level Network Threat Modeling

Threat modeling has been a hot topic in the last year or so. Microsoft has an entire center of information on the topic, ranging from threat defense webcasts to pointers to an excellent book written by Frank Swinderski and Window Snyder and published by Microsoft Press descriptively called "Threat Modeling". (Great book btw... here is my book review on it)

Some of my favorite articles include two from Peter Torr on the subject, the first being on "High Level Threat Modeling" and the second on "Guerilla Threat Modeling". What's interesting though is that all the information out there is focused on using threat modeling to write secure code. It is focused on finding threats to applications, which sometimes may include network access, but rarely goes past that.

With permission from Peter to format my thoughts in the same manner he did in his first article, I thought I would talk about how you can apply the same basic principles of threat modeling to analyze the risks that exist on your network infrastructure. The following is my take on "High Level Network Threat Modeling", borrowing HEAVILY from Peterís original thoughts:

Suggested Network Threat Modeling Process

This document outlines a suggested threat modeling process for "network operations" teams. It is designed to assist network operations in building high-quality threat models of their network infrastructure without turning everyone into a "security expert" and without overly taxing the resources of existing "security experts" that may exist in the team.

The process consists of six (possibly repeated) steps, outlined below in more detail:

  1. Preparation
  2. Brainstorming
  3. Drafting
  4. Review
  5. Verification
  6. Closure

Preparation

The head network administrator and his team, thinking like an adversary, identify Entry Points, Trust Levels and Assets of Interest. The team builds a network topology diagram of all primary systems with assets of interest and uses this information to build one or more data flow diagrams (DFDs) showing how data assets move around the network. They also identify all known consumers of the systems identified and which entry points these consumers use to access the assets on those systems.

  • This task should take around two hours for a reasonably-sized network with a handful of primary systems of interest. Larger networks may need to be broken up into smaller subnets to make them more manageable, ensuring that trust boundaries between subnets are well defined.
  • Network topology diagrams should include primary systems of interest, as well as primary network resources (routers, switches, firewalls, etc), and define who the owners/administrators are of those systems.
  • A "Catalog of Assets" should be documented to ensure that all assets of interest are enumerated
  • Actual threats are not enumerated at this stage; only the ways in which an adversary can interact with the assets.

Brainstorming

In this phase, the network operations team works from the network topology and data flow diagrams to perform a STRIDE-based modeling against the network. This will identify the threats against the assets on the network, and highlight any possible weaknesses or vulnerabilities that need to be addressed.

  • This task should take around 30 minutes to an hour for each primary system on the network that holds or accesses assets of interest. Additional meetings should be scheduled as appropriate if all avenues are not fully explored.
  • The results of the Preparation phase (entry points, catalog of assets, DFDs, etc) should be made available to the brainstorming attendees at least 2 days before the session so that the meeting doesn't just become a walk-through of the DFDs.
  • The existing documents (DFDs, catalog of assets etc) may be updated during the brainstorming session if new information comes to light, or if a particular system was overlooked.
  • Administrators responsible for managing any systems of interest defined must be present at the brainstorming session to assist with the process, answer questions, and so on.
  • All reasonable threats are enumerated at this stage, even those that already have mitigating strategies or that have been explicitly designed for. The point is not to just identify security weaknesses, but to document all known threats that the system must protect against, and how it does so.

Drafting

After the brainstorming session, the head network administrator takes all the ideas generated from the meeting and organizes them into a Threat Model document as appropriate. This document will contain the (potentially updated) DFDs, the entry points, trust levels, catalog of assets of interest, and all identified threats along with their mitigating factors (if any).

  • This task should take one or two hours, depending on the amount of the data captured in the brainstorming session

Review

After the threat model has been drafted, it is subjected to a normal review process like any other document. At this stage there may be minor (cosmetic) changes required to the document, or it may need to go back through a more thorough drafting phase. In the worst case, where a fundamental assumption is shown to be false or some other deep issue invalidates the work done so far, the process may need to go back to the original Preparation step and be repeated.

  • This task should take one to two hours, similar to a normal spec review.
  • The draft threat model must be made available at least 2 days before the meeting.
  • The members of the brainstorming session should be present, during this review process
  • Although the document may undergo cosmetic changes at this stage, it is not acceptable to merely patch it up if a serious hole is found in the document. The process must be re-started, and all assumption re-evaluated.

Verification

Once the threat model is reviewed, the network operations team updates existing network test plans and augments existing vulnerability assessment and penetration tests to verify assumptions made in the brainstorming phase and to perform directed testing on identified weaknesses.

  • Although this phase can actually start after the brainstorming phase, it is recommended to not do so until the review phase is complete and all possible changes are documented.
  • If necessary, external teams may be called in to help with penetration testing or other attack strategies if the details of a particular threat are not well understood, or if the mitigation strategies are believed to be lacking.

Closure

Based on the review, the head network administrator makes final edits to the threat model and publishes it (including all diagrams, results from vulnerability assessments and penetration tests etc) to the network operations team. The network administrator also logs findings for investigating and fixing of potential weaknesses in the network topology that were identified during this process.

  • This task should take one to two hours
  • Remember that threat modeling is never really done! New classes of attacks are always being found, and bugs in dependencies or changes that invalidate may manifest themselves as new vulnerabilities in the systems.

Epilogue

If you have read Peter's original article, you will find I pretty much plagiarized the whole thing. THAT'S THE POINT! Threat modeling is NOT about finding bugs in software. Threat modeling is about identifying risk by understanding the threats that an asset is susceptible to. Without knowing that, you can never build secure systems. Be it software applications, network topologies or physical security defenses. In this case, applying threat modeling to your network will allow you to identify risks to your organization by understanding the assets an adversary may be interested in, and how you can protect those assets with technical safeguards and security policy strategies. Remember that in the context of threat modeling, a threat cannot exist without an adversary having an interest in an asset. The goal in the threat model is to identify what threats exist, and identify mitigating strategies that can be put in place to lessen the impact and therefore lessen the risk to your business.

Posted by SilverStr at 01:15 PM | Comments (2) | TrackBack