Information Security Policies : A Cheat Sheet

Information security policies are a necessary evil.

The trouble is that very few organizations take the time and trouble to create decent policies; instead they are happy to download examples and cut and paste as they see fit. The resulting mess is often no good to anyone, and can often leave the business open to unforeseen issues.

Let’s look at a common scenario:

Your organization has been informed that you have to validate your compliance with the Payment Card Industry Data Security Standard (PCI-DSS). One of the daunting tasks ahead of you is having a policy in place that covers how your organization addresses all twelve requirements of the standard.

Do you have one in place?

No?

You’re in luck! Consider this your quick information security policy cheat sheet. In my opinion, the following are the bare minimum policy components required to start building an effective information security policy, which will meet the requirements of many frameworks (not just PCI-DSS).

Purpose
This section simply describes the reason why the policy exists (the “why”).

Scope and Applicability
This section states what assets, infrastructure, and personnel are covered by the policy (the “where”).

Policy
This section contains the overall body of the policy (the “what”).

Roles and Responsibilities
This sections contains information in regards to what roles (ie. IT Security Department, Helpdesk, etc.) are involved and what their responsibilities are in relation to the policy (the “who”).

Maintenance and Review
This section describes the frequency at which the policy is reviewed (preferably annually and/or after any significant changes have been made that will impact the policy).

References and Supporting Documentation
This section lists any related policies and/or procedures.

Terms & Definitions
This section lists any relevant terms and definitions contained in the policy.

A policy document should be a simple statement of the businesses position on the chosen topic, not to be confused with the procedural documentation which deals with how the policy is to be enacted. Procedures are sometimes necessarily much longer documents if they are describing processes which must be followed. System-specific security policies and corresponding procedures tend to fall into this category.

Ideally, the policy should be brief and to the point about the user’s responsibilities towards the information they collect, use, access or otherwise process, and to point them to the other relevant policies and procedures for the areas in which they operate.

By following these ideas, you should be able to create an effective information security policy, but more importantly have employees that are effectively looking after your organization’s assets. Information security policies provide vital support to security professionals as they strive to reduce the risk profile of a business and fend off both internal and external threats.

In short, what makes a good policy?

  1. It is relevant to your audience
  2. It is aligned to the needs of the business
  3. It is applicable to the compliance and/or regulatory frameworks in which you operate
  4. It is as short as possible.

This post was written as part of the Dell Insight Partners program, which provides news and analysis about the evolving world of tech. For more on these topics, visit Dell’s thought leadership site dell.com/futurereadyDell sponsored this article, but the opinions are my own and don’t necessarily represent Dell’s positions or strategies.

Professional social engineers wear white hats

In my line of work, I run across many RFPs (Request For Proposals) that involve complex, multi-step, security assessments. More often than not, the engagements call for a social engineering component. In short, social engineering is the art of manipulating people so they willingly give up confidential information. Companies are often hired to run social engineering campaigns to test the weakest link in the security chain.. humans.

A common misconception is that these companies are being malicious by default. Professional social engineers will not attempt to hack your Facebook account to find out your deep dark secrets and disclose them to your employer… they are simply testing your security awareness. It’s often easier to trick someone into giving you a password for a system than to spend the effort to crack into the system.

Common social engineering techniques

An attacker walks into a building and posts an official looking announcement to the company bulletin board that says the number for the help desk has changed. When employees call for help the individual asks them for their passwords and IDs, thereby gaining the ability to access both the company’s and employee’s private information.

An attacker calls random numbers at a company, claiming to be technical support. Eventually this person will find someone with a legitimate problem. The attacker will help solve the problem and, in the process, have the user type commands that give the attacker access to their computer systems.

An attacker contacts a target on a social networking site and starts a conversation. Gradually, they gain the trust of the target and then use it to gain access to potentially sensitive information.

Depending on the size of the company, an attacker, seeking entry to a restricted area secured by unattended, electronic access control systems, simply walks in behind a person who has legitimate access. The employee will usually hold the door open for the attacker or the attackers themselves may ask the employee to hold it open for them. The employee will, more often than not, fail to ask for identification.

An attacker leaves a malware infected removable device like a USB flash drive in a obvious location (bathroom, elevator, sidewalk, or parking lot), and simply waits for the victim to use the device. An employee might find it and insert the device into a computer out of curiosity. Doing so would allow the device to install malware on the employee’s PC, giving an attacker access to the victim’s PC and, perhaps, the company’s internal network.

These techniques are malicious in nature. The difference is that professional social engineers will never exploit any information they find as a result of these attacks. The results will be documented and presented to management so measures can be taken to mitigate similar attacks in the future.

Should you be worried?

Don’t worry if your employer decides to conduct a social engineering assessment. In the long run, the results will actually help improve both the company’s and employee’s security awareness.

Consider it training for the next time you get a call from “support”.

This post was written as part of the Dell Insight Partners program, which provides news and analysis about the evolving world of tech. For more on these topics, visit Dell’s thought leadership site PowerMore. Dell sponsored this article, but the opinions are my own and don’t necessarily represent Dell’s positions or strategies.

InfoSec Professional Development Close To Home

Last month thousands of information security professionals and enthusiasts alike flocked to the Black Hat and Defcon conferences, also affectionately known as security summer camp, in Las Vegas. Unfortunately many of us in the industry (myself included) are unable to attend those events due to work commitments, family vacations, or financial reasons. That doesn’t mean there are no options for low cost (or even free) professional development close to or from your home.

Cybrary launched on January 13, 2015. Their goal is “to provide an opportunity to learn IT and Cyber Security, to anyone, anywhere, who wants that opportunity.” They offer a wide range of free online training in various information security specializations, for example:

Irongeek.com is an excellent online resource that is run by Adrian Crenshaw of TrustedSec and Derbycon. He travels to conferences all over North America and records the talks, which he then posts for free on his website as a service to the infosec community.

Security B-Sides “is a community-driven framework for building events for and by information security community members.  The goal is to expand the spectrum of conversation beyond the traditional confines of space and time.  It creates opportunities for individuals to both present and participate in an intimate atmosphere that encourages collaboration. It is an intense event with discussions, demos, and interaction from participants. It is where conversations for the next-big-thing are happening.” B-Sides is a template conference design powered by grassroots organizers, that has spread to dozens of cities in several countries. It was born out of number of rejections to the CFP (Call For Papers) for Black Hat USA 2009.  A number of quality speakers were rejected, not due to lack of quality but lack of space and time.  Any constrained system must operate within the bounds to which it has defined itself.  Conferences constrain themselves to the eight hours a day for however many days they run.  B-Sides goal is to provide people with options by removing those barriers and providing more options for speakers, topics, and events. B-Sides events are usually free or low cost and almost always sell out quickly. *For the record, I’m also a B-Sides organizer.

SANS Cyber Aces Online makes available selected courses from the professional development curriculum offered by The SANS Institute. SANS goal in making these courses available as open courseware is to help grow the talent pool and accelerate the rate at which skilled cyber professionals can enter the information security industry – filling mission critical jobs currently going unfilled. The open courses are the same as those offered to information security professionals around the world and are focused on the fundamentals of cyber security.

Dell SecureWorks also offers security awareness training solutions, which include:

This list barely touches the surface. With resources like these, information security professionals really have no valid excuse for not staying current with industry trends.

Now I just have to find the time.

This post was written as part of the Dell Insight Partners program, which provides news and analysis about the evolving world of tech. For more on these topics, visit Dell’s thought leadership sitePowerMore. Dell sponsored this article, but the opinions are my own and don’t necessarily represent Dell’s positions or strategies.

 

Email security: A phishing tale

A few weeks ago my wife told me that she got an unexpected email from the Canada Revenue Agency. It wanted to initiate an Interac e-transfer of $980.99 into her account. The alarm bells immediately started ringing in my head.

  • We already received our tax refunds months ago.
  • They already have our direct deposit info, so an e-transfer doesn’t make sense.
  • It’s just too good to be true.

I took a look at the email she received. It definitely wasn’t from the CRA. Being the curious information security guy that I am, I decided to take the bait and click on the deposit link, in a virtual sandbox of course.

Screen Shot 2015-07-07 at 8.13.30 PM

As you can see above, the site is looking for valuable personally identifiable information (PII) that no one should have to provide over the Internet. I used my trusty Shodan browser plug-in to determine that the server resides in Romania. Now I know for a fact that CRA wouldn’t have an office in Romania!

Without entering any information, I clicked continue.

Screen Shot 2015-07-07 at 8.29.41 PM

Chrome warns me one page too late that this site may be suspect. I understand the risks to my security, so I visited the infected site.

Screen Shot 2015-07-07 at 8.31.21 PM

Now here’s where it gets really interesting. It is looking for information that can cause a world of grief if it fell into the wrong hands.

Needless to say, I didn’t enter any information or go any farther.

The evolution of phishing

Phishing attacks have been around for years. Financial motivation is still alive and well in these types of attacks. This method of duping people into providing their PII is still around (and will most likely be for years to come), but the targets are largely individuals versus organizations.

Phishing attacks have also evolved in recent years to include installation of malware as the second stage of the attack.

How can you protect yourself from phishing attacks? Be suspicious of emails asking for confidential information. Legitimate companies and organizations will never request sensitive information via email. Here are some other tips:

  1. Watch out for generic-looking requests for information. Fraudulent emails are often not personalized, while authentic emails from your bank often reference an account you have with it (even authentic emails from your bank will ask you to contact a representative directly). Many phishing emails begin with “Dear Sir/Madam” and some come from a bank or an organization with which you don’t even have an account.
  2. Never use links in an email to connect to a website unless you are absolutely sure they are authentic. Instead, open a new browser window and type the URL directly into the address bar. Often a phishing website will look identical to the original — look at the address bar to make sure that this is the case.
  3. Don’t get pressured into providing sensitive information. Phishers like to use scare tactics and may threaten to disable an account or delay services until you update certain information. Be sure to contact the merchant directly to confirm the authenticity of their request.
  4. Make sure you have anti-malware software installed to help combat phishing.

Now please pardon me while I respond to an email from a Nigerian prince.

This post was written as part of the Dell Insight Partners program, which provides news and analysis about the evolving world of tech. For more on these topics, visit Dell’s thought leadership site PowerMore. Dell sponsored this article, but the opinions are my own and don’t necessarily represent Dell’s positions or strategies.

How startups can take a risk-based approach to network security

You have a great idea for a startup. You come up with a solid business plan. You pitch it over and over and over. You get funding. Everything is in place. Off you go!

Then the data breach happens. Your customers aren’t happy. Your investors aren’t happy.

What went wrong?

Before I dive into what went wrong, let’s talk about what a startup actually is.

A startup is a company that is typically:

1. Expected to scale dramatically
2. Five years or younger
3. Pre-revenue

For most startups, security isn’t a priority. Security teams and budgets are small, if they even exist. Getting a product or service to market in the shortest amount of time is priority number one. They need to start generating revenue as soon as possible. Implementing effective network security controls often delays the process.

Startups cannot afford to have any kind of extensive change management process. The ability to continuously deploy code to production with minimal QA and peer review has become part of the code deployment process, and there is often no time to perform any type of secure code review. It’s very important to develop a secure coding framework, such as OWASP (Open Web Application Security Project), depending on the underlying technology.

In the world of startups, things often move extremely fast. The ability to quickly identify any potential vulnerabilities and fix them is paramount. Startups need to create an environment where employees are motivated to identify security incidents and report them without worrying about any repercussions. Security awareness is extremely important in startups. They have to look for creative ways to educate employees about security breaches and incidents. New vulnerabilities turn up almost daily, and it is critical that they identify them with scanning tools and fix them in a timely manner. These tools should be able to do the following:

  • Run vulnerability scans on a regular basis to identify any anomalies.
  • Categorize known vulnerabilities based on a risk rating scheme.
  • Suggest remediation steps, if any exist.

Startups should try to use the least number of tools to accomplish as many things as possible. When done correctly, one may be able to address any security issues with a single tool that provides integrated results. This is critical for startups, because they have limited budgets.

It is also very important that startups understand potential business threats before they can protect their data. Implementing risk analysis frameworks, such as Open FAIR, can certainly help to:

  • Perform risk assessments.
  • Assign threat levels.
  • Evaluate any appropriate controls.

Last but not least, the quickest way to reduce an attack surface is too close unneeded services and protocols. If you don’t need them, shut them down immediately.

Information security doesn’t have to be difficult or expensive for startups that use a risk-based approach to security. They can implement increased security in a cost-effective manner by targeting well-known risk areas from the start. By performing an analysis and focusing on high-risk areas, startups that have limited budgets and teams can still create strong security.

This post was written as part of the Dell Insight Partners program, which provides news and analysis about the evolving world of tech. For more on these topics, visit Dell’s thought leadership site Power More. Dell sponsored this article, but the opinions are my own and don’t necessarily represent Dell’s positions or strategies.

AtlSecCon 2015: signs of a truly future ready industry

Let’s be honest. Atlantic Canada isn’t the first place you think of when you want to #BeFutureReady. Events like the Atlantic Security Conference (AtlSecCon) are working hard to change that.

Before we go any further, I do have something to confess. I am one of the organizers of the conference. I wasn’t when it started five years ago, but I saw the potential even then.

The conference has grown steadily over the past five years, with this year being particularly notable with attendance at an all-time high and increased sponsorship from companies such as Dell. We also had world-class speakers like Mkit CEO Matias Katz, who came all the way from Argentina for the third year in a row.

Here are three future-ready takeaways from AtlSecCon:

1. The future is bright: Since its inception, student attendance has normally been low at AtlSecCon. This is most likely due to the fact that it happens over the span of two weekdays. It wasn’t the case this year. There were record numbers of student attendees from well-known educational institutions such as Dalhousie University and the Nova Scotia Community College (NSCC). This goes to show that institutions like these realize that best place to learn isn’t necessarily in a lecture hall. Networking with industry professionals can go a long way in helping to guarantee a bright future.

2. The future is female: AtlSecCon had an amazing volunteer crew this year, and they were all female NSCC students enrolled in various IT programs. As we all know, the “lack of women in tech” issue has been around for more than a few years. We at AtlSecCon have always recruited women to attend and speak at our conference. This year was no exception:

  • Well-known TED speaker Keren Elazari, Research Fellow at Tel Aviv University, spoke about the good that hackers can do.
  • Ksenia Dmitrieva, senior security consultant at Cigital, showed attendees how to use Content Security Policy to protect  Web applications.
  • Anna Manley (a fellow Cape Bretoner), an articled clerk at Sampson McDougall, asked the audience, “Can the police legally compel you to provide the encryption key for your encrypted laptop?”

3. The future is local: While we had no shortage of come from away* speakers, our crop of local speakers grows every year.

  • Ben Goodspeed, principal at Goodspeed IT Consulting, discussed formal mathematical methods in security research.
  • Paul Halliday, senior software developer at Critical Stack, talked about squert, a widely-used open source Web interface for network/enterprise security monitoring that Halliday built, in Nova Scotia.
  • Daniel Merritt, software development consultant at Merritt Consulting, introduced us to traffic logging in network forensics.
  • Peter Morin, senior specialist — IS Response at Bell, showed us how to take a forensic approach to incident response.
  • Colin O’Flynn, electrical engineering consultant, not only showed us the technical workings of side-channel power analysis and glitching attacks, but also how they apply to real systems, and what this means to those designing those systems.
  • Julien Savoie, network administrator at Universite Sainte-Anne, cut through the hype and answered some basic questions about Tor and how well it stands up in a post-security breach world.
  • David Shipley, director, Strategic Initiatives, Information Technology Services, showed us how the University of New Brunswick is using policy, practice and technology to enhance cybersecurity.

Do you think Atlantic Canada is future-ready now?

*Atlantic Canada slang

This post was written as part of the Dell Insight Partners program, which provides news and analysis about the evolving world of tech. For more on these topics, visit Dell’s thought leadership site Power More. Dell sponsored this article, but the opinions are my own and don’t necessarily represent Dell’s positions or strategies.

 

 

 

 

 

 

PenTest vs. VA: One Of These Things Is Not Like The Other

As a QSA, I’m often required to review the results of a vulnerability assessment and a penetration test as part of an overall security assessment. When I ask my clients for each report, I often get this response:

“Aren’t they the same?”

They aren’t. While somewhat similar in concept, they produce distinctly different results.

Penetration tests (commonly known as PenTests) are used to identify methods of exploiting vulnerabilities with the intention of finding security weaknesses in a system, potentially gaining access to it, its functionality and data. It’s a mainly manual process that can include vulnerability scanning and other automated tools. At the end of the engagement, an extensive report is generated. Its contains a description of each vulnerability verified and/or potential issue discovered. More specific risks that vulnerability may pose, including specific methods how and to what extent it may be exploited. Examples of vulnerabilities include but are not limited to SQL injection, privilege escalation, cross-site scripting, or deprecated protocols. PenTest engagements may last days or weeks depending on the scope of the tests and size of the environment to be tested. Tests may grow in time and complexity if efforts uncover additional exploits.

Vulnerability scans (commonly known as VAs) identify, rank, and report vulnerabilities that, if exploited, may result in an intentional or unintentional compromise of a system and/or network. Typically a variety of automated tools are used in combination with manual verification of identified issues. These tools list the potential risks posed by known vulnerabilities, ranked in accordance with NVD-CVSS base scores that are associated with each vulnerability. Scans usually take a short amount of time, which can range from several seconds to several minutes per scanned host.

A vulnerability assessment should be performed regularly to identify and remediate known vulnerabilities on an ongoing basis. A penetration test should be performed at least annually and after significant changes in the information systems environment to identify exploitable vulnerabilities in the environment that may give a hacker unauthorized access to the system.

While vulnerability assessments and penetration tests are a requirement for PCI DSS compliance, it would be beneficial for companies to include the procedures in their overall security program even if they aren’t required to be PCI compliant. When used in conjunction with each other, they are an excellent indicator of a company’s security posture.

This post was written as part of the Dell Insight Partners program, which provides news and analysis about the evolving world of tech. For more on these topics, visit Dell’s thought leadership site PowerMore. Dell sponsored this article, but the opinions are my own and don’t necessarily represent Dell’s positions or strategies.

 

 

 

 

OWASP – What is it?

I conduct security assessments for a living. More often than not, web application security is part of the engagement. You would be surprised at how many organizations don’t consider information security beyond the bare minimum when it comes to web application development.

For the record, I’m not a web application developer and I tell that to my clients up front.

That being said, when I (or my clients) need guidance I often refer to OWASP as a best practices baseline.

What is OWASP?

OWASP stands for Open Web Application Security Project. It is a not-for-profit charitable organization focused on improving the security of software. Their mission is to make software security visible, so that individuals and organizations worldwide can make informed decisions about true software security risks.

What is the OWASP Top Ten?

The OWASP Top Ten is an awareness (not a standard) document for web application security. It represents a broad consensus about what the most critical web application security flaws are.

Adopting the OWASP Top Ten is perhaps the most effective first step towards changing your software development method to one that produces secure code. The list is as follows:

1. Injection: “Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.”

2. Broken Authentication and Session Management: “Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.”

3. Cross-Site Scripting (XSS): “XSS flaws occur whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.”

4. Insecure Direct Object References: “A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, or database key. Without an access control check or other protection, attackers can manipulate these references to access unauthorized data.”

5. Security Misconfiguration: “Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, and platform. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.”

6. Sensitive Data Exposure: “Many web applications do not properly protect sensitive data, such as credit cards, tax IDs, and authentication credentials. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.”

7. Missing Function Level Access Control: “Most web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access functionality without proper authorization.”

8. Cross-Site Request Forgery (CSRF): “A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. This allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.”

9. Using Components With Known Vulnerabilities: “Components, such as libraries, frameworks, and other software modules, almost always run with full privileges. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications using components with known vulnerabilities may undermine application defenses and enable a range of possible attacks and impacts.”

10. Unvalidated Redirects and Forwards: “Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.”

If you’re an web application developer, you should become very familiar with this list, especially if you’re in the area of ecommerce, because some well-known security standards (eg. PCI-DSS) require validated proof that you are developing secure code.

This post was written as part of the Dell Insight Partners program, which provides news and analysis about the evolving world of tech. To learn more about tech news and analysis visit Tech Page One. Dell sponsored this article, but the opinions are my own and don’t necessarily represent Dell’s positions or strategies.

 

 

 

Just When You Thought You Had A Handle On PCI-DSS 3.0

As I mentioned in a previous post, PCI-DSS 3.0 (Payment Card Industry Data Security Standard) came into effect on January 1.

PCI-DSS 3.1 is on now its way, thanks to vulnerabilities like P.O.O.D.L.E.Shellshock, and Heartbleed.

The PCI SSC (Payment Card Industry Security Standards Council) continuously monitors threats and vulnerabilities in order to keep the security standard up to date.

The National Institute of Standards and Technology has identified SSL (Secure Sockets Layer) – a protocol meant to establish encrypted communication between a server and a client – as no longer acceptable for data protection.

Due to the inherent weaknesses of this security protocol, there are currently no versions of SSL with the ability to provide strong cryptography. This is why an updated version of the PCI Data Security Standard (PCI DSS) and the Payment Application Data Security Standard (PA DSS) is necessary.

According to NIST, “The proper management of cryptographic keys is essential to the effective use of cryptography for security. Keys are analogous to the combination of a safe. If a safe combination is known to an adversary, the strongest safe provides no security against penetration.”

The problem lies in the way the information is encrypted when being transmitted from a client to a server.

The solution is the dropping of SSL in favor of the TLS 1.2 protocol. SSL and the Transport Layer Security (TLS) are both mechanisms to protect sensitive data during electronic dissemination across networks. TLS 1.3 is currently being developed; the goal is to add extra measures to avoid exploitation and mitigate encryption-related issues.

To ensure the continuity across the payment card industry, the PCI Council expects that the PCI DSS 3.1, once published, will be effective immediately. That being said, the new requirements will need some time to be implemented and the PCI SSC will give some time to allow organizations to look into the new requirement and implement the changes.

Considering that there is no known way to address the weaknesses discovered in the SSL protocol, it is strongly recommended that all organizations that handle cardholder data look into the possibility of switching to a strong cryptographic protocol, such as TLS, as soon as possible. There are a number of ways to do this for WindowsLinux, and FreeBSD servers and clients.

This post was written as part of the Dell Insight Partners program, which provides news and analysis about the evolving world of tech. To learn more about tech news and analysis visit Tech Page One. Dell sponsored this article, but the opinions are my own and don’t necessarily represent Dell’s positions or strategies.

Threat modeling at a moment’s notice

If information security professionals want to stay current, they need to be on top of the latest trends and technology in their field. They also need to be open to acquiring new skills and methodologies at a moment’s notice.

To make a long story short, today I was assigned a security architecture review project by my boss. It calls for application threat modelling using a risk assessment model.

I have no experience with application threat modeling.

Research Powers Engage!

What is threat modelling?

Threat modeling is an approach for analyzing the security of an application. It’s a structured approach that enables you to identify, quantify, and address the security risks associated with an application. Threat modelling is not an approach to reviewing code, but it does complement the security code review process. The inclusion of threat modelling in the SDLC can help to ensure that applications are being developed with security built-in from the very beginning. This, combined with the documentation produced as part of the threat modelling process, can give the reviewer a greater understanding of the system. This allows the reviewer to see where the entry points to the application are and the associated threats with each entry point.

I’m also looking at two risk assessment models. STRIDE and DREAD.

STRIDE is a system developed by Microsoft for thinking about computer security threats. It provides a mnemonic for security threats in six categories.

The threat categories are:

DREAD is part of a system for risk-assessing computer security threats previously used at Microsoft. It provides a mnemonic for risk rating security threats using five categories.

The categories are:

  • Damage – how bad would an attack be?
  • Reproducibility – how easy is it to reproduce the attack?
  • Exploitability – how much work is it to launch the attack?
  • Affected users – how many people will be impacted?
  • Discoverability – how easy is it to discover the threat?

In the end it doesn’t matter what model I choose… as long as the engagement comes to a satisfying end for both the client and myself.

The client will be happy and I will have gained a new skill set for future engagements.

What have you learned today?

This post was written as part of the Dell Insight Partners program, which provides news and analysis about the evolving world of tech. To learn more about tech news and analysis visit TechPageOne. Dell sponsored this article, but the opinions are my own and don’t necessarily represent Dell’s positions or strategies.