Posted: 10 Nov 2008 02:53 PM CST
Here's a top 10 list of things to do to rehabilitate if you want to take a break from being secure. If you're thinking paranoia, think again. Reading up on a post on ha.ckers.org there is a list of things you can (but should not) do.
Step 1: Sign up for a MySpace account. Facebook is fine too. Actually why not all of the social networking platforms? It's easier to keep in contact with everyone if you do. Make sure to fill out each form field completely and accurately!
Step 2: Pick a password that is easy to remember and make sure to write it down on a sticky note. Feel free to tell your friends in case they want to use your account too. Better yet, make a list of all your passwords and change them all - to "password". If someone is annoying and makes you use a number, "password1″. An upper case, a number and a special character use "Password+1″. Now tear up that pesky list you just made. You're living easy now aren't you?
Step 3: Download every third party widget, gadget, movie, game you can think of onto your social networking profile. Cuz that's fun. And make sure to put every gory detail about who you are, where you live, what your birthday is, what your mother's maiden name is, what you like and dislike, etc…. And feel free to update it regularly with any and all personal information that may have changed. That way people can get to know you better.
Step 4: Log into your newly created webmail account and email all your friends your likes and dislikes. Don't forget to enable HTML rendering so you can see all the neato pictures! And don't feel afraid of hitting reply to those spam emails. That'll help them know that you're not interested.
Step 5: Start downloading toolbars and desktop applications galore so that you can get your real time stock quotes, shop for beanie babies and know what the weather is like in Iceland at all times.
Continue reading "A break from being secure"
Posted: 10 Nov 2008 11:27 AM CST
Following my previous Monday blues ranting article, today is a good Monday - albeit even closer to my exams than the previous week - nevertheless between correcting assignments and fixing my system at home I've had my hands full this weekend.
My Epatec3850 ebox is currently a sitting duck as I am still unsure what the problem with it is. Instead I've decided to go greener by selling off one of my P4 machines only to get an AsusB202 ebox. Needless to say, I love the box. Consuming only 20W I know feel better that amidst the rising electricity tariffs, I should be consuming less power than a full blown PC (450W). Performance with WinXP is excellent and I even run my Debian box inside VMWare without too much performance loss when using the system for normal PC usage. Only thing I did was beef up the memory to 2Gb. My WRT54G WDS network is also much more stable as I reset all the boxes and flashed back with the standard DDWRT 24vSP1 firmware. Running with WPA2-AES over WDS all my devices happily connect and talk to each other without any drops or losses. (fingers-crossed) all is working in unison.
Back to the security topic of interest... is an article written by Sean M. Price on the September ISSA journal - an extension to the McCumber Cube to Model Network Defense.
Firstly, the McCumber cube was developed by John McCumber as a way to model risk management. It provides the security practioner with a way to consider risk from different perspectives employing three different aspects namely, information states, countermeasures and security services. Sean does an excellent job giving examples of how the cube can used in practice.
Building on the CIA triad, Sean talks about extending it to reduce reliance on inexact estimates and improve risk by focusing on attacks while coming up with explicit countermeasures. So in addition to the above cube to achieve the security goals of CIA attacks are added to the equation.
ATTACK + Information State + Countermeasures -> Security Goal
What is cool is that is Sean systematically broke down attacks to fit the model in way that makes more sense. The images below explain the logic behind it and I truly think it makes sense associating specific attacks with a selected information state and particular security service.
The proposed extension now takes the below form
The proposed extension to the McCumber cube takes risk assessment from a different angle. Why not consider specific threats and the estimate of their likelihood and then identify countermeasures that should be in place to defend against them. A lack of existing countermeasures from a defense-indepth perspective (which is a vulnerability) equates to more risk for the system.
A model which is closer to a state of reality as opposed to something which relies on estimates is preferable. Often the estimates used in risk assessments have little research or quantitative results to support their assertions.
The result is a better evaluation of system risk and a more discrete identification of countermeasures needed to defend a network against specific types of attacks - and I am all over it...
Posted: 09 Nov 2008 07:47 PM CST
Posted: 09 Nov 2008 04:06 PM CST
At the Hack in the Box conference in Kuala Lumpur, Malaysia at the end of last month, Dino A. Dai Zovi (formerly of Matassano & @stake) made some comments about the relative security of the ARM vs. x86 architectures. He was quoted as saying “That [the use of an x86 processor] will make the iPhone x86 and that will make a lot of attacks easier…” in an InfoWorld article which as was blogged about by Joel Hruska on the ArsTechnica website in an article called ‘Researcher: ARM a safer bet than x86 chips’.
Dai Zovi is an increasingly well-known cyber security research. He won the April 2007 MacBook hacking contest, presented at Black Hat on Hardware Virtualization Rootkits and at Hack in the Box on Mac OS XPloitation. A podcast interview with Dai Zovi is available SearchSecurity.com.
If Dai Zovi is correct and the ARM chips are indeed a safer bet from a security point of view than the x86 chips that is of course very important news from a control systems security point of view. ARM chips are used in control systems technology, specifically some PLC’s. Although HMI level technology is usually x86, mission and safety critical systems are generally PLC controlled. If one chip architecture provides a better security foundation than another, that would be an argument for preferring that architecture, especially for mission & safety critical systems.
Another ‘theoretical’ argument is that the ARM chips, like the PowerPC chips are RISC rather than CISC based. Some security researches assert that in general, the more complicated something is the more difficult it is to secure. By that argument one might assert that because RISC based chips are simpler, at least at the time of the initial design, they might provide a better foundation for building secure systems.
In Hruska’s review of the Dai Zovi claims, Hruska suggests that a serious comparison of the security properties of the ARM and the x86 chips should “account for the protective mechanisms built into both a device’s OS and its actual hardware” which seems pretty sensible.
This brings me to the discussion I am hoping to start. Do some chipset architectures provide a better security foundation for PLCs and if so, which one’s and why? Or, are there so many issues after the initial chipset architecture decision that the security implications of one chip architecture over another is really just in the noise?
This posting includes an audio/video/photo media file: Download Now
Posted: 07 Nov 2008 05:47 PM CST
Good afternoon everybody! I hope your day is going well.
Here are today’s Interesting Information Security Bits from around the web.
That’s it for today. Have fun!
Subscribe to my RSS Feed if you enjoy these daily Interesting Bits posts.
Posted: 07 Nov 2008 01:03 PM CST
A friend of a friend of mine is an IT consultant that works with many companies (for the sake of blog anonymity, let's call him Steve). At a party last weekend, Steve mentioned that most of his customers are not very large - in fact, some are small brick-and-mortar shops. Regardless of size, they all have two things
Posted: 07 Nov 2008 01:00 PM CST
I was in Chicago this week for the Tech Target ISD event giving a presentation on Information Centric Security. Like most of the people who flew in from other parts of the country for this event, we were so focused on the election and getting out to vote before we flew in, that we completely missed the fact that Obama would be speaking about a mile from the Hyatt Regency at McCormick Place. Most of us simply forgot that this was Obama’s home, and that Grant Park would be the likely place for any speeches that were to be given.
Dave Mortman was kind enough to show Adam Dodge, Andy the IT Guy, and myself around, and take us to dinner at the Russian Tea Room off Adams street. When we were done with dinner around 8:30, we wandered over to Michigan Avenue for some people watching. The crowd was just starting to build, with thousands of people walking down the street to the entrances of Grant Park. While early, there was no doubt about the outcome for the attendees at this point. The most amazing thing was the sense of energy and genuine elation in the crowd as they walked down the street. Not the wild frenzy you get in New York when the Yankees win a pennant, but more a feeling of relief and joy than anything else. We booked it back to the Hyatt and watched the election results, and Obama’s subsequent speech, on television before calling it a night. I am very glad that I got a chance to be there, albeit on the periphery, as the mood & energy of that crowd was something I have never experienced before.
All in all a very nice trip, and hats off to the Tech Target team for putting on such a well run, professional event. The only downside of the whole week was my Southwest flight having to make an unscheduled stop due to running out of fuel(!!!!), and having to present opposite Captain Virtualization on Wednesday morning.
Oh, one minor point of interest. While I was at the Hyatt, I noticed that the hotel has a new revenue model: Tel-evator. This is a little marketing device television that they are putting into the elevators to deliver targeted marketing to conference attendees while they take the ride to and from their rooms. Being a security guy, as well as someone who gets annoyed at marketing messages constantly shoved at me, I was thinking “how could I hack this”. In the one minute ride I got as far as determining these little devices are nothing more than laptops running Windows Vista, with content being pushed over the 802.11 wireless connection, before I had to go to the conference. That night when returning to my room, I saw that someone else had the same idea. The ‘Tel-evator’ was now at an MS-DOS prompt, running a script, before rebooting into Vista. Beaten to the punch I guess. If you were the one who hacked the system, shoot me an email and let me know what you found.
It was a relatively quiet week on the security front, with no major disasters or announcements. And from what I hear, Comrade Mogull is alive and well.
Webcasts, Podcasts, and Conferences:
Favorite Securosis Posts:
Favorite Outside Posts:
Blog Comment of the Week:
Tod on the Felon Database post:
“You know that Felonspy.com is a joke, right? More specifically, it’s almost certainly political satire of the sex offender databases.”
I do now, Tod- I do now.
Posted: 07 Nov 2008 09:33 AM CST
This is an update to yesterdays blog entry. I rarely update entries but this must be updated. Turns out that that the attack is not as serious as first reported, but anyways it is a vulnerability. Read more here.
I heard some rumors of the topic just a while ago and now ran into some online press articles, for example here. Eric Tews and Martin Beck has made advances in breaking WPA TKIP encryption. The attack is not done with a dictionary attack but combining a mathematical method with tricking the wireless router into sending large amounts of data.
It means that there is an actual concrete attack against WPA TKIP existing that has nothing to do with your initial key length and dictionary attacks, but is a problem in the protocol itself. The end result of the attack is that the TKIP key is broken in about 12-15 minutes and communication from the router to the connected device is revealed (but not vice versa).
Mitigation based on current cracking time could be to set the wireless router to change the temporal keys in a reasonable short time (if such option is available in the router). This probably helps until there are more advances in cracking the TKIP key.
Another option is to move to WPA2 pre-shared key mode which uses CCMP instead of TKIP. Only problem is that not all devices support WPA2 and a WPA2 capable router apparently falls back to WPA in such cases where a legitimate client uses only WPA.
Lets see what other research arises from this, probably the cracking time will decrease and maybe the communication can be broken the other way too (client->AP) if reasonable amount of traffic can be generated.
Posted: 07 Nov 2008 07:46 AM CST
Commtouch, one of our technology partners, has been honored with the Deloitte Technology Fast 50. Read the full article.
Posted: 07 Nov 2008 05:01 AM CST
This tool has been around for a LONG time in some form or another, some of you old-skool guys may remember a package called SATAN, this was the best semi-automatic security analysis tool around back then. From SATAN and it’s development came SARA, which is now in it’s 3rd generation. Advanced Research’s philosophy relies...
Read the full post at darknet.org.uk
Posted: 06 Nov 2008 07:00 PM CST
Win Signed, Pre-Release Copies of Daemon, Hard Cover Edition Read the EH-Net review (content/view/125/2/) and the first four chapters in their entirety. Due to the success of this electronic grassroots movement, Daemon has been acquired by the Dutton imprint of Penguin books. Dutton plans on publishing a new edition of Daemon in hard cover that will be highly promoted and includes new material. Part of that marketing agreement means that Verdugo Press can no longer sell the first edition. As luck may have it, EH-Net had 20 copies which went to 20 lucky attendees of ChicagoCon 2008f (http://www.chicagocon.com/) who received...
Posted: 06 Nov 2008 05:45 PM CST
Good afternoon everybody! I hope your day is going well.
Here are today’s Interesting Information Security Bits from around the web.
That’s it for today. Have fun!
Subscribe to my RSS Feed if you enjoy these daily Interesting Bits posts.
Posted: 06 Nov 2008 04:51 PM CST
Congratulations to the elected president. I was watching his speech on Tuesday and thought that it was important enough that I allowed my nine-year old son to stay up past his bed time to watch the entire event. Apparently millions of people all over the world couldn't stay up that late, but still wanted to watch (or re-watch) a video recording the next day. As a result, many individuals have now been mis-led by a Trojan.
Hundreds of thousands of users whose computers are being infected by malware that bears Obama's name will hopefully remember not to open suspicious emails. Websesnse, as well as several other security vendors, issued warnings about this Trojan. The malware is distributed via compromised sites. According to Websense, "Some of the email attacks contain links to a file called 'BarackObama.exe' which is hosted on a compromised travel site."
Posted: 06 Nov 2008 12:22 PM CST
Yes, I am an Eminem fan. I will meet him someday, and tell him that I think he have done a great job!
My closet cleaning is not of this kind, however, I am working my way through my RSS feeds. And one of the things that is backlogged is the opportunity to give you - yes, YOU, a full pass to the CSI 2008 conference, taking place in DC (guess that means Washington DC for us Other People).
But - to get the FREE pass, you need to help me clean the closet. I would like you to help me find the worst post on my blog. Bring it out to the light, and post your comment below. I will choose one of the posters (that is you) as the winner on wednesday 12. november. Yes, it is a short notice. But if you plan to go, or is in the area anyway, this is a great saving.
The rest of you will get a 25% discount.
So - bring out your vacuumers and help me find the worst post on my blog!
Go on! I will not bite you!
Posted: 06 Nov 2008 11:38 AM CST
Posted: 06 Nov 2008 10:19 AM CST
I was reminded by my fellow bloggers that I have been remiss on my blogging responsibilities and have not written about our recent announcements of a new mid-market edition WAF and PartnerSphere program.
We started our partner program, OpenSphere, a few years ago and have been fortunate to attract a good number of partners; in fact, many are currently adding considerable value to our customer base. Our partner program is divided into two components: 1. technology partners (under the OpenSphere umbrella) and 2. our channel partners, which we are calling our PartnerSphere. Yes, there is a pattern here...
What is the goal of this new push? Simple: to expand the overall reach of our solutions to segments of the market that are looking to solve security and compliance problems, but have previously been out of reach of our direct sales force or do not require extremely high-performance solutions. Yes, there is another world out there...
Posted: 06 Nov 2008 07:51 AM CST
Typically when I am referring to “permission” I am advising my students or audience to seek permission before performing any sort of security testing. This week I have been looking at permission in a different light, as it relates to the file systems, services, and programs on Windows systems. As a defender it is important to understand and set the appropriate permissions. Doing so can close some of the gaps when it comes to privilege escalation, that is increasing my level of access to the exploited system. This is especially important on systems that communicate with control systems. Proper access control and permissions can help slow down attackers and prevent them from accessing control systems and other components of the system (such as password databases).
There are many techniques for privilege escalation and abusing permissions, for example I cam across this article which show the following example:
at 21:01 /interactive "cmd.exe"
The above command will start and interactive command shell at the specified time. On certain versions of Windows (XP/2000), this command shell would execute with SYSTEM privileges. However, I did some testing on recently patched Windows Server 2003 systems and this command did not work and the system reported “Access is denied”. Proper permissions matter and its worth the time and effort to configure them on your system.
Posted: 06 Nov 2008 06:33 AM CST
In "The Scenario" I laid out the scenario that we want to assess the risk for. Simply put, a rather routine Windows security template exception. Using the RMI FAIR Basic Risk Assessment Guide (BRAG) as our guide, let's jump into this.
Note: In the interest of brevity, I will try to strike an appropriate balance between descriptiveness and conciseness when characterizing scenario components. When in doubt, error on the side of what may seem like too much documentation. Not only does it make the assessment more defensible now- it helps in the future if you have to revisit it or need to compare a similar scenario against it.
1. Identify the Asset(s) at Risk: A non-redundant, non-highly available Windows 2003 Active directory member server that runs a sales tracking application that is infrequently used by CSRs to service customers for detailed sales order information. The most likely threat scenario is non-availability of the server to the business (CRSs) due to 3rdpartysalesapp.exe being leveraged to fill up the hard disks on the server with useless data by the TCOMM below.
2. Identify the "Threat Community" (TCOMM): This is always an interesting discussion since there can be multiple threats that can come into contact and attempt to take action against an asset. For this scenario – the first two that come to mind are malware and a malicious server administrator; I will only perform the assessment using one of them.
a. Malware. Based off the given information, I am less inclined to stick with malware because the server is very isolated from the most likely attack vectors one would expect malware to be propagated by (email, Internet browsing, outbreak in lesser trusted network space, etc..). Now please understand, I am not stating that this server cannot be attacked by malware, I am stating that compared to my other threat community, a malware infection on this server has a lower probability of occurring then the other.
b. Malicious Server Administrator (SA). I am choosing this TCOMM as the most likely for several reasons:
i. The server is not accessible from the Internet; which reduces the chances of attack from the traditional "hacker" TCOMM.
3. Threat Event Frequency (TEF): TEF is the probable frequency, within a given timeframe, that a threat agent will act against an asset. For this step, I am going to select LOW or once every 10 years. Here is why:
a. There was an incident in 1999 where a malicious internal employee was able to successfully take action against Initech. The circumstances then compared to this scenario are different but we have a starting point from an analysis perspective.
b. In general, SA's are pretty trustworthy individuals. Initech Novelty, Inc. is a small company with minimal IT staff. It is reasonable to assume that most of them would not have reason nor intent to intentionally attempt to bring down a production server. From a scenario perspective, there is nothing stated that should lead one to assume there is a reason for one of the existing SA's to take malicious actions.
c. Initech Inc. has already been assessed by a 3rd party for ISO 27002 and given a CMM score of around 3.5 for the "human resource security management" section. An assessor could assume that Initech, Inc. is performing a good level of due diligence to ensure they are hiring trustworthy individuals as well as ensuring there are deterrents in place to hopefully minimize malicious behavior (could be a combination of both preventive and detective controls; policy, monitoring, training, etc..).
4. Threat Capability (TCAP): The probable level of force that a threat agent (within a threat community) is capable of applying against an asset. Now keep in mind that we are focused on the TCOMM in the context of a weakened security template that allows a non-Windows provided executable to write to "%systemroot%\system32" – not the threat population. For this step I am selecting MODERATE; between %16 and %84 of the threat community is capable of applying force against the server and vulnerability in focus for this scenario. Here is my reasoning:
a. The TCOMM would have unfettered and privileged access to the server and be able to easily launch an attack.
b. The TCOMM would most likely have privileged knowledge of the weakened security template.
c. It would not take much effort for the TCOMM to find or quickly create a method to exploit the vulnerability.
5. Control Resistance (CR; aka Control Strength): The expected effectiveness of controls, over a given timeframe, as measured against a baseline level of force. The baseline level of force in this case is going to be the greater threat population. This is important to understand. So, threat community is a subset of a greater threat population. So we can have internal employees as a threat population; but we have narrowed our focus in this scenario to a small subset of the population which is articulated in the Step 2. Pardon the redundancy, but Control Resistance is analyzed against the population – not the threat community. For this scenario, I am selecting a Control Resistance value of HIGH; or stated otherwise, the controls on the server are resistant to 84% of the threat population. Here is my reasoning:
a. A very small percentage of the Initech Novelty, Inc. workforce would ever have privileged knowledge of the weakened security template.
b. The skills required to remotely exploit the vulnerability are not trivial. It's possible that someone may have the skills, and tools, but it is not probable that a large or even moderate percentage of the "threat population" does for this scenario.
6. Vulnerability (VULN): The probability that an asset will be unable to resist the actions of a threat agent. The basic FAIR methodology determines vulnerability via a look-up table that takes into consideration "Threat Capability" and "Control Resistance" (this is on page seven of the BRAG).
a. In step four – Threat Capability (TCAP) - we selected a value of MODERATE.
b. In step five – Control Resistance (CR) - we selected a value of HIGH.
c. Using the TCAP and CR inputs in the Vulnerability table, we are returned with a vulnerability value of LOW
7. Loss Event Frequency (LEF): The probable frequency, within a given timeframe, that a threat agent will inflict harm upon an asset. The basic FAIR methodology determines LEF via a look-up table that takes into consideration "Threat Event Frequency" and "Vulnerability" (this is on page eight of the BRAG).
a. In step three – Threat Event Frequency (TEF) – we selected a value of LOW; once every 10 years.
b. The outcome of step 6 was a VULN value of LOW
c. Using the TEF and VULN inputs in the Loss Event Frequency table, we are returned with a LEF value of VERY LOW
*Note: the loss magnitude table used in BRAG and the loss magnitude table for the Initech, Inc. scenarios are different. The Initech loss magnitude table can be viewed below as well as at the Initech, Inc. page of this blog.
8. Estimate Worst-Case Loss (WCL): Now we want to start estimating loss values in terms of dollars. For the basic FAIR methodology there are two types of loss: worst case and probable (or expected) loss. The BRAG asks us to: determine the threat action that would most likely result in a worst-case outcome, estimate the magnitude for each loss form associated with that threat action, and sum the loss magnitude. For this step, I am going to select DENY ACCESS, in the RESPONSE loss form, with a WCL value of LOW. Here is why:
a. The server going down results in it not being available- thus access to it is denied. The most likely loss form to Initech Novelty, Inc. is the cost (IT response) in bringing it back up.
b. Since this is "worst case", the longest I could see this server being down is five business days. Based off the given information, this would result in one call to the service center not being able to be properly serviced because the application is down. I estimate response loss from a customer service center perspective to be less then $100.
c. The effort required by IT to rebuild the serve is 1-2 hours – easily under $1000 dollars.
d. Even though the application is not considered "mission critical" to Initech Novelty, Inc. – a prolonged outage could impact other processes as well as increase the response impact.
9. Estimate Probable Loss Magnitude (PLM): In step eight, we focused on worst-case loss – which in reality for this type of a scenario is probably not a practical step. Now we are going to focus on probable loss. Probable loss is for the most part always going to be lower then "worst case" loss. The BRAG asks us to: determine the threat action that would most likely result in a worst-case outcome, estimate the magnitude for each loss form associated with that threat action, and sum the loss magnitude. For this step, I am going to select DENY ACCESS, in the RESPONSE loss form, with a WCL value of VERY LOW. Here is why:
b. Since this is "probable loss", the longest I could see this server being down is a few hours, not more then a day. Based off the given information, this could result in one call to the service center not being able to be properly serviced because the application is down. I estimate response loss from a customer service center perspective to be less then $100.
c. The effort required by IT to rebuild the serve is 1-2 hours – easily under $1000 dollars.
10. Derive and Articulate Risk: At this point in the basic FAIR methodology we can now derive a qualitative risk rating. Using the table on page 11 of the BRAG worksheet, we use the LEF value from step seven and the PROBABLE LOSS MAGNITUDE value from step nine to derive our overall qualitative risk label.
a. LEF value from step seven was VERY LOW.
b. PLM from step nine was VERY LOW.
c. Overall risk using the BRAG table on page 11 is LOW.
So how would I articulate this to a decision maker or someone that is responsible for this exposure to the organization?
“A security template modification is necessary for this application to function properly. The modification somewhat weakens the security posture of that server. The most likely threat to the server would be a disgruntled server administrator that wants to bring the server down. Our assessment is that there is a very low likelihood of loss and even if it did occur there would be minimal impact in terms of response costs to Initech Novelty, Inc; (expected loss of less then $1000; worst case loss less then $5000).”
Final thoughts: Some of you that have read the scenario and assessment are probably thinking that this seems like a long process. As with anything new it takes a few iterations for one to become comfortable. Over time, a simple scenario like this could easily be done in a few minutes mentally – maybe five minutes if you have to document some of your justifications (which I suggest you always do).
I look forward to any feedback you might have! If anyone has any suggestions for a future scenario – please let me know.
Posted: 06 Nov 2008 06:14 AM CST
A Windows server administrator (SA) has contacted the Initech Novelty, Inc. Security Manager to get a formal security exception to modify the security template that allows the executable of a third party sales tracking application (3rdpartysalesapp.exe) to have write access to the "%systemroot%\system32" directory on a Windows 2003 server. The sales tracking application has been designed to create temporary files in the "%systemroot%\system32" directory. This server fulfills a "member server role" within the Initech Active Directory domain.
1. The Windows servers runs a web-based intranet sales tracking application. It is accessed over TCP 443 (SSL) from the user segment. The application's data actually resides on a separate database server in a separate data networksegment. The application is not considered a mission critical application.
2. The Windows server sits on a dedicated network segment dedicated to Initech internal application servers. This segment is firewalled off from the user segments, the database servers as well as the network segments that have Internet facing servers. All firewall configurations are least privilege in nature. There are both logical and physical security controls that facilitate network segmentation.
3. The servers on the internal application network server segment are centrally managed from an OS patching and Anti-Malware perspective (in other words, they do not make direct connections to the Internet).
4. Initech, Inc. mandates via its information security policy that Windows server security templates be applied to all of its servers; specific to its role within the enterprise. In the case of this scenario, a default Microsoft provided Windows server 2003 "member server" security template has been applied to the Windows 2003 server.
5. This particular sales tracking application server is not clustered or considered to be highly available. It is estimated that it would take Initech Novelty, Inc. IT personnel between 1-2 hours to restore the server from the most recent daily back-up and another 1-2 hours for application testing.
6. The application is used by Initech Novelty, Inc. customer service representatives to get detailed information about a sales order that is not available within their regular CSR application. About one out of every 250 calls to the Initech Novelty, Inc. service center require access to the application in focus for this scenario.
7. The Initech Novelty, Inc. service center is open seven days per week between the hours of 8 AM EST and 10 PM EST. Average daily volume of calls that are sales transaction related are 50.
8. Initech Novelty, Inc. has calculated CSR employee costs to the organization (salary, benefits, etc.) to be $60 per hour. Information technology employees are listed as $85 per hour.
9. Finally, the server in this scenario is not in scope for PCI-DSS compliance (Payment Card Industry Data Security Standards). Access to credit card "primary account number" (PAN) or any other card information is not possible in this application.
In the next post, we will perform the risk assessment using the RMI FAIR Basic Risk Assessment Guide (BRAG) as our guide.
Posted: 06 Nov 2008 06:06 AM CST
I participated in an advanced FAIR training session recently with a very small group of peers from my employer. It was great training, great collaboration, and was actually the formal kick-off to a special project I am leading regarding risk quantification. During the course of this training, I was reminded of a few things that I think are important to remember about risk scenarios – especially given the upcoming posts where I will post risk scenarios and my analysis.
1. Training risk scenarios – whether reflective of actual incidents or purely made up – need to be structured enough to minimize "what-if" and or hypothetical questions. During this training event, I brought to the table what I thought was a "simple" risk scenario that I expected would take maybe 10 minutes to work through – it took about 30 minutes (there were 7 people chiming in). Everyone has a different perspective when looking and dealing with risk. So, to be effective at writing risk scenarios, I think each scenario needs to be framed up to account for at least 80-90% of the relevant information one needs to truly assess the scenario. Anything greater then 90% may be time prohibitive. Feel free to provide comments about the structure of the risk scenarios I present – what is the missing information you need? Ask yourself if the information you need is something that would only be applicable in your environment versus universal information that should have been included in the scenario.
2. I will use the FAIR methodology to assess the risk for these scenarios. There are four FAIR certifications that can be earned – you can get more details at RMI's website. I am currently certified as a "FAIR Analyst" and a "FAIR Senior Analyst". For the risk scenarios I post, I will reference a freely available FAIR tool called the "Basic Risk Assessment Guide" (BRAG) and stick with basic FAIR concepts for the actual risk assessment. This approach should allow for an easier understanding of FAIR concepts and overtime, the complexity of the scenarios will be easier to digest. Of course, I would recommend reading the FAIR white paper but I am hoping that the risk scenarios will still give an adequate representation of FAIR.
3. In the BRAG that is available from RMI - in the loss magnitude section - there is a table for loss magnitude severity with dollar value ranges. The values listed in the BRAG should be replaced with dollar value ranges more reflective of your company – especially if you start to adopt FAIR and use it on a regular basis. Determining these ranges should be an exercise that includes information security, IT, legal, business folks, and probably others I have not listed. In the case of the Initech risk scenarios – I have modified the loss magnitude severity table and posted it on the Initech, Inc. page.
Posted: 06 Nov 2008 05:39 AM CST
Today is a special day for me. It was three years ago on October 24, 2005, that Blue Box Podcast #1 was uploaded. It was an 11-minute episode where I talked about... Skype security, SIP security, IETF, VOIPSA and some other VoIP security news..... (Hmmm... sounds lot like our recent shows, too, eh?)
Jonathan Zar joined me a week later on Blue Box Podcast #2 and we've been going ever since. We've now produced over 112 episodes, had close to 245,000 downloads of our various shows, met some amazing people, learned a lot along the way... and hopefully helped you all learn a lot out there as well.
Thank you to all of you who have joined with us on this journey... whether you've listened to our show from the very beginning (and we know of a couple of you who have) or have only recently joined in... thank you!
And now... on to the next three years... :-)
Posted: 06 Nov 2008 04:12 AM CST
No surprise here, the malware authors are leveraging on the social engineering aspect of the US presidential elections. In less than half a day Google Adwords adverts and custom malware was popping up conning users into a sense of security by using Obama’s name. Malware purveyors have wasted no time capitalizing on Barack Obama’s...
Read the full post at darknet.org.uk
Posted: 06 Nov 2008 02:39 AM CST
Many pro-IPv6 people would love to have IPv6 everywhere now and even yesterday. What I'm noticing is that most of common operating systems IPv6 stack have at least one vulnerability. I can call this phenomen by pressure cause imaturity. Vendors, geeks, please don't forget the security before operations adage or you will get powned by yourself in a future day.
Posted: 05 Nov 2008 09:49 PM CST
When I was in college some of the "cool dudes" used to have a contest. If you did not meet anyone at a bar or club by the time it got late, say 2 or 3am, you had the ugly girl contest. The thinking was you were not going to meet anyone great at that late hour, so you might as well go for something that you could laugh about tomorrow. Of course you would never call that girl again after that night. She was a 3am'er. Me, I was lucky to meet anyone I could, so wasn't cool enough to play that game, but heard about it plenty.
Hearing the story about how Google pulled out of the joint advertising deal with Yahoo reminds of that story. When Microsoft was trying its best to pick up Yahoo, Google treated Yahoo like she was the prettiest girl on the block. They were willing to do just about anything to keep Yahoo out of Microsoft's hands. Jerry Yang and the team was only too happy to point to its Google deal as a poison pill that Microsoft would not swallow. Of course the Microsoft-Yahoo deal never happened and the Google partnership was a big reason why.
Now that the Microsoft-Yahoo deal is off the table, Google dropped the Yahoo partnership as soon as the water got a little rough. I think Google was only too happy not to go through with the deal. Yahoo is after all a competitor still. They dropped Yahoo like the girl they met at 3am the night before. In the cold, light of day they could laugh about it, but they would be damned before they continued hanging out with them. Google got what they wanted by keeping Yahoo out of Microsoft's hands. When they were done they threw away Yahoo like a cheap date.
Shame on Yahoo for being used and abused like that. I could understand why a Yahoo shareholder would be upset with this.
Related articles by Zemanta
|You are subscribed to email updates from Security Bloggers Network |
To stop receiving these emails, you may unsubscribe now.
|Email Delivery powered by FeedBurner|
|Inbox too full? Subscribe to the feed version of Security Bloggers Network in a feed reader.|
|If you prefer to unsubscribe via postal mail, write to: Security Bloggers Network, c/o FeedBurner, 20 W Kinzie, 9th Floor, Chicago IL USA 60610|