You've discovered the Big Question in cyber risk management. There is no easy answer. I've written entire papers on the subject. The problem you have identified is to determine what data to use as a basis for a quantified likelihood calculation. The challenges you face are: there is not enough data in your context the foundation for the risk context is under constant change (technology is constantly changing, and new threats and vulnerabilities are constantly emerging, creating "perfect uncertainty" even if you had lots of data) There are a few approaches to take: Use a Qualified approach based on expert opinion (and quantify a range of opinions over time for extra rigor) Use a sliding scale of impact and determine what quantified data you do have for each range of impact Use an adjacent context that does have enough data for you to use (partners, competitors, others "just like you") Replace "likelihood" with "ease" in your calculations Assume a longer time scope and assume that all events will happen eventually, which leaves you with assessing impact alone Combine the above approaches based on available relevant data and stakeholder requirements As you can guess, I could go into a book's worth of exploration for each point. If you want a book, I can recommend https://www.amazon.co.uk/How-Measure-Anything-Cybersecurity-Risk/dp/1119085292 . I do not agree with everything in the book or the authors' conclusions or basis, but it is a great place to start in your thinking. The one thing I caution you about is "false accuracy". Just because you have data and you can use a formula to generate a valid output does not mean that your conclusion is at all correct or can accurately represent likelihood. I see too many risk professionals fall into the trap of "But I made a fancy graph with lots of data points! It must be right!" All risk management is a guess and a bet against the future. And sometimes, spending too much time trying to get accurate about something that hasn't happened yet is just a waste of time.

The auto complete makes no difference at all. The wallet generation uses a dictionary that is part of the https://en.bitcoin.it/wiki/BIP_0039 . This dictionary have 2048 words, and by default it uses 12 words, giving you around 132 bits of entropy. Even if the attacker knows the first letter of every word, he already have the dictionary and autocomplete does not make his work easier. And the work is impossible in practical terms: it does not matter if the attacker guesses the private key only after the heat death of the Universe, because it means Bitcoin exchanges aren't available anymore. Electrum even have a https://electrum.readthedocs.io/en/latest/seedphrase.html this.

They certainly can be interconnected, which means that they usually need to be considered together. Sometimes they will have the same requirements, and sometimes they will have conflicting requirements. For example, consider a server room that has a door with electronic access control on the door. Normal staff should not be allowed into a server room, because: Server rooms are dangerous places and untrained people shouldn't be left along in them. Server rooms hold sensitive information, and only trusted individuals should be allowed in. So having swipe-card controlled access meets both safety and security requirements. However, what happens if the power to the door control goes out? From a safety perspective, it should be possible to open the door if the power is out (so you can escape the building) - it should fail into a "safe" state. From a security perspective, the door should remain locked if the power goes out (so unauthorised people can't get in) - it should fail into a "secure" state. If you only considered one side (safety or security), then you'll probably end up with a system that only has one of them. You need to consider both sides, and then find an appropriate balance between them based on the organisations requirements (or implement additional controls that allow you to meet both requirements, such as a door that fails closed with no power, but has a mechanical override).

The most predominant issues with DLP I currently see are in regards to what it can actually retrieve. Often this already omits encrypted connections such as HTTPS (unless SSL certificates are used to implement a MiTM). Furthermore there are some legal issues in most European countries regarding privacy and proportionality of collecting data which is one of the biggest reasons DLPs are not really selling over there. There are some strict guidelines regarding data retrieval and processing in the EU: Notice—data subjects should be given notice when their data is being collected; Purpose—data should only be used for the purpose stated and not for any other purposes; Consent—data should not be disclosed without the data subject’s consent; Security—collected data should be kept secure from any potential abuses; Disclosure—data subjects should be informed as to who is collecting their data; Access—data subjects should be allowed to access their data and make corrections to any inaccurate data; and Accountability—data subjects should have a method available to them to hold data collectors accountable for following the above principles. In comparison to the US for instance, if a European employee has a folder on his computer titled "personal", even on a company machine, the data within this folder may not be accessed. The definition of personal has also been kept quite broad allowing for wide interpretation. And personal data is not allowed to be processed unless certain conditions are met: Transparency (subjects should always be notified what data is being processed) Legitimate purpose Proportionality (When sensitive personal data (can be: religious beliefs, political opinions, health, sexual orientation, race, membership of past organisations) are being processed, extra restrictions apply.) The data itself can also not be sent to other countries outside of the European Union, unless certain conditions are met Violating (even accidentally ) any of the above rules will make you legally liable and can cause a lot of hurt to your company. So a machine collecting almost everything which passes over your network (and which decrypts SSL streams) is a real risk if something goes wrong with the data it collected or if someone decides to take a peak in it, as your company will be held responsible for it.

As you suspect, this is an issue of terminology. You're probably looking for lists of vulnerabilities, but to be safe I'd like to explain a little bit more. I'm afraid the whole thing is rather complicated, but worth it in the end! Before I begin, I should point out there are many different approaches to Information Security that may have their own terminology (I'm an ISO 27000 man myself.) So other answers may use different wording. So, you have your system that you are working on, and you want to protect it from harm - that's what Information Security is, the systematic protection of information from harm. For harm to happen, there have to be two things. A "threat", which is someone who will cause harm (either deliberately or by accident), and a "vulnerability" which is a way that the threat can do harm. Two examples: Your competitor ("threat") accesses your system via SQL injection ("vulnerability") in order to steal your customer list ("harm" - specifically a "loss of confidentiality") Joe in shipping ("threat") can't figure out how your system works ("vulnerability") and always puts in the wrong value for widget crank setting. ("harm" - specifically "loss of integrity"). You can find lists of threats and lists of vulnerabilities online. Threats tend to be easier to figure out yourself though - who might realistically want to harm your system? Who might accidentally harm your system? So mostly you find lists of vulnerabilities. The OWASP top ten is a great place to start. Where does risk come into this, then? Risk is a measurement that combines the likelihood of a threat exploiting a vulnerability with the harm that would come about if they did. Risk assessment is used to figure out which threat and vulnerability combinations have a risk higher than you want to accept, so you know that you need to "treat" them - do something about them. For example, if your competitors are all honest, and you are carefully handling your SQL input, and everyone knows who your customers are anyway, then the risk in example one is very low and so not worth worrying about. (Well, not worth spending money on, at least.) Alternatively, if Joe is careless and the wrong widget crank setting will make your product catch fire, then the risk is high, and you need to do something about Example 2 ASAP. Here's the thing though - each risk assessment is pretty much unique because the threats and vulnerabilities you face are in a unique combination. Something like the OWASP list is not a short-cut. It's more a list of things you should check to make sure you haven't missed any of them.

The recent compression-related attacks all work on the same principle: some chunk of bytes is compressed, containing both a data element that the attacker chooses, and a data element that the attacker wants to uncover. The resulting compressed length is used as a binary oracle in successive "guesses" from the attacker, who progressively rebuilds the secret value, one byte at a time. This cannot work with static pages, because static pages are static. By definition, this means that their contents does not change often (i.e. never except by explicit action of the site administrator), and, in particular, the attacker does not get to put his own data in them. It can be pointed out that compression is a matter of performance and, as such, is not warranted until performance problems have been duly noticed. I suggest that you first deactivate compression altogether, and see if this works well for you. If, and only if, you notice excessive network consumption or latency, does it become relevant to try higher compression levels.

I see two sides on this: most government bodies I review/audit tend to believe that because they secure everything then they are the most secure and that is the way it should be! In actuality the organisations that go down the security nazi route usually end up more open than those who are pragmatic about it. For example, locking down your users too hard with smart cards for physical and desktop access may be fine, but if you make it impossible for them to do their job (if they have been handed work from someone else who is off on holiday, but the work is assigned to a different card) then they get very good at workarounds - like sharing cards; like pretending to lose cards to get replacements and hoping the old ones don't get invalidated for a while, etc. most private sector organisations want to spend the bare minimum on this sort of thing to meet the regulator's requirements so the opposite argument holds true: I need to argue the case for more security. At the end of the day it comes down to understanding the organisation and working out an appropriate level of control which meets their risk appetite and is understandable at board level. Appropriate here may not actually be very secure, or it may be Fort Knox with bells on - every organisation is different!

The cost is not from the vulnerability but from the risk. Namely: A vulnerability is that which can potentially be exploited to put at risk your information assets (e.g. a buffer overflow). A threat is a context element which will try to snoop on or damage your information assets (e.g. an existing group of attackers who would benefit from such actions in some way). A risk is when a threat meets a vulnerability, and they get along well, and marry, and have offspring. The cost is something applied to whatever you do with the risk. For instance, the cost of ignoring the risk is, roughly, the cost of the damage resulting from the actualization of the risk. On the other hand, the cost of fixing a buffer overflow is purely development & deployment cost, since it removes the vulnerability. The art of risk management is to strike the right balance between corrective actions and acceptance (the "right balance" being relative to the risk management goals, which depend on the organization). Bottom-line: cost is about what you do, and depends on a lot of contextual elements, in particular threats. You cannot estimate any meaningful notion of cost without taking the context into account. You cannot attach a cost to a vulnerability, or even to a risk; the cost is a property of a set of actions (since "doing nothing" is such a set, some cost is always incurred).

The claim can be substantiated by checking the successful exploit rates against (e.g.) Secunia databases, or by checking the latest, say, 100 security advisories from Microsoft TechNet (the management loves Microsoft sources ) or e.g. US-CERT. Every time there's an exploit for something that was known at the time the exploit took place, that's a vulnerability that patching would have avoided. A very effective display can be done by installing Secunia Personal on any given computer. You will almost certainly (I'm not kidding you!) find several vulnerabilities: that can be exploited by a crafted email. That is: every mail they receive could potentially contain the exploit. that can be exploited remotely. That is: connect that laptop to the hotel's WiFi, and more often than not the occupant of any nearby room (in case of workshops abroad, very often a colleague or competitor) can pwn your laptop. Maybe they won't. But they could. that can be exploited remotely on a server. That is: your web site might already be yours no longer. If it has a private area, and maybe sensitive document for the sales force... "How would you like it if some cracker were to leak this information to the highest bidder?". Just explain to them in layman's terms what exactly a vulnerability that can allow a remote, unauthenticated attacker to execute arbitrary code on a vulnerable system could mean for their business.

Special firms either degauss, destroy or melt the harddrives. Harddrives are magnetic data. Magnetism can be destroyed by either: Degaussing (changing the magnetism) Heating the drive (melting) (which destroys/changes the magnetism) Hammering (shock) (shock damages magnetism somewhat, but the denting of the drive makes it very difficult to read the surface, as metal deforms, the surface area changes as well thus making it even more difficult to determine what is and isn't a sector) Drilling (removes sectors altogether, physically changes the layout of the drive like hammering, generates a large localised amount of heat as well) shooting (same as hammering, but more extreme) Chemical corrosion (if the magnetic substrate is removed from the platters altogether, there's nothing left to recover) Shredding, there's plenty of services that offer to shred your harddrive which leaves you with nothing but metal scraps, nothing to recover there. So, Would simply submerging the drive render it un-usable? No. Probably not to an experienced forensics or recovery team. What WILL kill the drive is corrosion of the platters, so it depends on what you add to the water, how long it stays in there, what the platters are made out of and how good the people trying to recover the data are.

One solution: put the database server in your trusted network, make sure you only allow database ports through. Maybe a better one would be to: Turn on the OS firewall on the db server and lock it right down Give it a DMZ NIC and a Trusted Net NIC Make sure your database security is locked down and everything is blocked in and out except the traffic you want (i.e. allow AD traffic on the trusted NIC and not on the DMZ, etc.) That would give you, logically, the topology you described, but it will increase the risk if your database server is compromised. Is it worth keeping the database server off the domain? That'll mean you should be able to have only the SQL ports open. Maybe set up a pair of named instances? One for external one for internal - then you can logically separate everything.

At a glance, the NIST guide you've linked to describes the goals and backgrounds that would be conducted in an assessment, but there's nothing there you can point to and say, "We followed these steps." It doesn't provide a quantifiable, verifiable process that an auditor can confirm. You'll have to find another resource or develop your own.

Blocking IP with no reverse DNS means punishing people who have bad ISP. It seems that most ISP have now understood that reverse DNS should be in place, but occasional mishaps still happen. There is no, to my knowledge, "legitimate" reason not to implement reverse DNS, but I have seen it happen a lot, and rejecting requests on that ground seems harsh, and also unlikely to have to appropriate pedagogical effect. Also, note that for IPv6, with the automatically allocated addresses (computed from the machine MAC address), a missing reverse DNS is likely to be the norm.

Your ISP can know your password any time it's sent unencrypted over your internet connection. If you don't want them to know your password, don't send it unencrypted over the internet: Avoid login pages that use HTTP (always use HTTPS and don't visit sites with expired or invalid SSL certificates) Don't use FTP or other services/protocols that don't encrypt your password in transit Also follow general security guidelines for passwords, such as never reusing the same password. Additionally, if you are worried that your ISP (or anybody else in between you and the remote server you're communicating with) is watching you, then you also need to take additional steps, such as: Ensuring that all websites you are logged in to are using HTTPS, so that your cookies can't be snatched from the HTTP request (you're logged in to this site, where HTTPS isn't available, so your ISP can already log in as you here if they want to) Verifying you are talking to the right server (for example, with SSH, ensure you use fingerprint verification and take notice if a server's fingerprint changes). If you are only worried about your ISP (or your government), you can improve your position significantly by using an offshore VPN so that all of your traffic is routed through a server outside of their reach. Your data will still be sent unencrypted over the internet, but will be encrypted between the VPN and you, which is enough to prevent your ISP from reading it.

Despite the gigabytes written on risk management, I don't think there is a consistent, coherent terminology for risk management. So the answer to your question is local; unless you define "ignore" differently from "accept" within your risk management program, there is no difference. That said, I would suggest that if I were one of the decision makers, I would treat the two differently. Even if I were to accept a risk, I would continue to monitor that risk, periodically re-assess that risk, and consider assigning risk triggers and risk metrics. I'm accepting that risk today because of my evaluation of the risk likelihood and impact, the cost and efficacy of my potential responses, and my priorities. Next month those factors may change. In my mind "accepted" risks are still managed, but "ignored" risks are not.

So basically what the requirement is saying is that you need to assign one primary function per server. The server you've described sounds like it runs a few applications for production users to utilize. This would be classified as an "application" server. However, you've also mentioned that there are multiple applications on that server, some touch the CDE indirectly and others do not. While this server would be considered to have one primary role, it brings the controls of the applications that don't touch the CDE into consideration. If it were me, I would move the applications that don't interact with the CDE off of that box and move them to a different server, in a different segment if possible. If you don't have a segmented network (which you should really, really do) then everything is in scope anyway, so this advice doesn't matter.

It would depend on the version of Wordpress, in general the idea is that you need to patch your software and harden it to make it secure. But it's not that Wordpress is any less safe than Sharepoint. Wordpress is in general well maintained and CVE's are patched or fixed quite rapidly. So if you keep up with these then it's safe to use Wordpress. (do mind that you need to keep track of your plugins as well) If you don't do this in general, then your Sharepoint will probably be as insecure as your Wordpress (or any other software that's on your Intranet for that matter). But saying that software X is insecure without providing any facts to support the statement is a bit stupid. EDIT To compare intranet vs internet, the likelyhood is lower, but the impact is the same as on the internet.

I liked the organization your site. But these are my first thoughts: The problem statements you mentioned are definitely some problems but they are too high level. In the sense that there are already many companies doing the same stuff in SAAS. What differentiates you and your service? This is something which is not clear to me. I have used controlcase platform in the past and it still needs consultants to classify and input majority of the information and "intelligence". I think if you work a bit more on the product management side of it and find out a "perceived" gap in current solutions, it may work wonders. Just solve this and go inside out solving and building one pain point at a time. GRC is a huge field - implications, assessment methodology varies widely based on the type of industry. Although the mother framework is the same. So it may be a good idea to first choose one industry which is closer to you and sell to them first solving very specific problem in that industry. This will also help you gain some early traction quicker instead of becoming "everything to everybody".

As a security professional, it is often best to 'outsource' this calculation to the business. For example, if you identify a vulnerability which you can demonstrate is easy for an unskilled attacker to exploit to destroy the customer database, and the operations team estimate bringing it back from backups will take 4 hours, including checks, ask the business owner what that will mean to them in terms of cost or impact. The business should have a view on indirect costs created by customers avoiding the company, and an advertisement complain to restore confidence. Once they have told you the cost, your side - helping to define protection - is much easier, as @growse said. The equation usually does not work on a one-to-one though. You'd think if cost of breach is higher than cost to fix then carry out work to fix, but more commonly we see it being more like if cost of breach is more than 10x cost to fix then remediate.

In my experience management doesn't like to listen to clever analogies. Depending on the person they care about the bottom line in dollars or hours of productivity. I would explain: The actual bottom line is that a compromise of our data will cost the company approximately X dollars + Y hours to recover. This is Z% likely to happen given the malware that is on this machine. A new install will cost A dollars + B hours to recover. You pick the appropriate action. It's short and clear and doesn't really leave them any room to argue. They will clearly understand the risk and should make the right decision.