You are asking about a pure risk assessment methodology. And it's quite simple at a high level. what are the inherent, relevant risks in the context (vulnerabilities matched with threats)? what controls are in place to address those risks? how effective are those controls against those risks? what's left that is unaddressed? Threat catalogues are meant to help inspire thoughts to come up with a list of relevant risks in context. They are not meant to be a complete list. Vulnerability tools look at technical risks that are discoverable through technical analysis. There is a whole universe of risk that is outside of technical vulnerabilities.

Yeah.... you don't do something like that yourself when "I'm not so good at web security." Have a look at PCI-DSS and the horrible horrible things that you can be liable for if you don't do things properly. Instead, you should use something like Authorized.net to take care of handling that part for you. Also, I really hope that you are using an existing e-commerce solution instead of writing your own. The amount of things that you can screw up when you have no idea what you are doing is so scary it's not even funny.

You would have two types of risks: There could be a flaw in the server code. This is a generic situation for every server, but a Remote Desktop server is known to be relatively complex, and thus probably has more exploitable bugs than, say, a SSH server. Microsoft themselves offers an additional product called Remote Desktop Gateway (previously known as Terminal Services Gateway) which acts as an intermediate step. The gateway runs a "normal" SSL server, on port 443, and can perform a user authentication, but it is much simpler (and therefore assumed to be stronger) than a full-blown Remote Desktop server, since it does not actually handle the Remote Desktop protocol -- it just forwards it to the actual Remote Desktop server. Note that among possible "flaws" in Remote Desktop is configuration, in particular with regards to certificates. A basic Remote Desktop server can use various encryption layers, some custom, some encapsulating SSL. A critical point is that, depending on the configuration and on how the user handles it, the client might fail to properly validate the server's certificate (in particular when the server's certificate has been automatically generated and is self-signed). In that case, the client is open to a Man-in-the-Middle attack. There again, the Gateway makes things sturdier, in that it enforces a very Web-like SSL server model which is harder to configure wrong. If a user is allowed to open a session on the server, on virtue of presenting a matching password, and that password is weak, then an attacker could run a dictionary attack, which means trying possible passwords until the right one is found. This would be an online dictionary attack, and you might be able to automatically notice such an ongoing attack by the huge amount of "failed login" events. However, if the attacker succeeds, then he gets to run arbitrary code on the machine. Privilege escalation on a local machine tends to work (locally exploitable flaws are much more common than remote flaws) so you basically have lost. The only good defence against weak passwords is to educate users into choosing stronger passwords. As a mitigation measure, you can also restrict Remote Desktop access to some specific users; by default, only members of the local Remote Desktop Users group will be allowed to open a session. Your first step should be to actually decide who is allowed to do that on the machine (As @Hennes suggests, given that the machine is a Domain Controller, the list of people who are allowed to open a session on it should be limited to just the administrator; or you are doing it wrong). Remote Desktop Gateway is not free and tends to require an extra machine. A cheaper alternative is to deploy a VPN solution like OpenVPN (the core software is GPL, no license needed). This is functionally equivalent. It won't do anything against weak passwords, though.

I am not sure about all types of malwares but http://contagiodump.blogspot.in/ is a good place to start . Also you can get samples from malware.lu and virushare.com .

Unsure of where you can get a list from, but the IOC Editor may have visibly similar options. Meaning, you can browse the options to see what is available, and how it works. I'd also have a look at IOC Finder to see what options are available on that as well.

From an end user perspective, i usually give the reader and surrounding plates a good whack with my fist and i try and peel back any of the faceplates with my keys or a knife. The fact of the matter is, the best quality skimmers aren't detectable. POS machines can be hacked which results in an almost undetectable scenario. Your best bet, if you want to avoid being skimmed, is to cash out at a teller at the bank From a company perspective, I've come across two new defenses against skimmers recently from perusing ATM manuals (I'm doing some work with them at the moment and have all the manuals/specifications) 1) Sensors to detect any obstruction in front of the the card-reader for extended periods of time it'll trigger an alert. These sensors are light sensors, proximity sensors and beam sensors depending on the ATM in question. These are both mounted inside the card reader and around the device in general. 2) Sensors to detect constant RF signals. If you transmit for more than xx seconds (i won't mention the exact time frame) it'll trigger an alert. From the manual: Radio frequency (RF) detection is used for detection of analogue transmitting spy cameras fitted to the ATM for purposes of fraudulently capturing card holder PIN entry. RF detection does not trigger an alert but provides additional supporting information to an alert if a fraud device is detected by a sensor at the same time as an RF detect alert. Additionally: HSFD consists of the following elements: Control board RF detect sensor (optional) From one to six sensors Cellular modem(to transmit alerts), with separate antenna (optional). The following diagram shows an overview of the High Security Fraud Detection (HSFD) feature. Dashed lines indicate optional components: Alerts usually go to a back to base central monitoring solution somewhere controlled by the bank that owns the ATM There's a new proof of concept Anti-Skimming technology called SRS “Secure revolving system” that got announced recently, there's a video of in in action here. Original story here The actual SRS device looks like this: Basically it accepts the card 'side on' (as opposed to the usual card entry method) and then rotates it 90 degrees before accepting it. This basically prevents any face plate being attached over the device and makes it very difficult to position a skimmer.

Nothing is ever really secure. That's true as long as people are still people. If you ask any developer about their programming project they can probably give you two-to-three hypothetical scenarios where someone could exploit their code (and how). In every development project there are always high-level decisions to be made, many in regard to the level of security the project warrants. This happens either because of lack of budget, lack of planning on the part of the development (or management) team, and simple oversight (can't see the forest for the trees). Because everything that we as a people do these days interfaces with some sort of external connection whether it's an ethernet cable, bluetooth dongle, wifi card, a cell tower, an ATM card reader (maybe a stretch), or even external USB devices such as thumb and hard drives there are never any secure machines. Software audits should happen frequently (if not multiple times a day), but the frequency of the audits depend on a few things: Is it a production machine in a production role? How much do you need to keep the machine running? (Is it mission critical?) What kind of protections are in place on the system? (antivirus, firewall, etc) What kind of access avenues do outsiders have into the system? Unknown security threats that arise after a software (or hardware) is released are commonly patched. Since most patches are released publicly as security updates, software updates, and firmwares this makes all other versions of the software(s) prior to the most recent currently patched version vulnerable to the now documented exploit the patch is supposed to be fixing. An undocumented attack where no patch exists is referred to as a zero-day attack. Here is a recent warning about a Microsoft Internet Explorer 8 Zero day attack vector. Most major antivirus / security monitoring applications will have a Bayesian pattern matching system sometimes referred to as a heuristic analysis in place that tries to prevent anything that looks similar to a documented style of attack that is happening live on a machine.

It really depends on your point of view. From the outside, the "script kiddie" is, nominally, the wannabe attacker who uses tools written by other people (the "scripts"), without really understanding what is going on. Everybody uses tools written by other people (if only operating systems, C compilers, libraries...), but some people have a certain understanding of how things work internally, and could, at least potentially (if free time was free), rewrite these tools from scratch. The script kiddie himself does not think of himself as a "script kiddie", of course. In his view, he is an "elite hacker", and the other people are script kiddies. The expression "script kiddie" is meant as a disparaging designation, to insist on the alleged youth of the individual and its associated inherent shame. To consider youth as shameful by nature, you have to be young. Old people don't think of youth as a disgusting fact to hide, but as a lost treasure. When somebody uses the expression "script kiddie" too often, you can often infer that this somebody is himself not very old, and a metaphorical scripty smell probably lingers around his person. A more neutral, less emotionally charged classification would be about competence. Attackers are more or less competent at what they do. Just like anybody. The less competent attackers, which other script kiddies are prone to point out and mock as "script kiddies", will run their tools (collected on the Internet), and if the off-the-shelf tools don't succeed in the attack, they soon give up. More competent attackers will adapt their tools to the specific situation; they see the tools more as a generic framework for attacks than the actual instruments. Given the above, to avoid being seen as a script kiddie, the trick is to distantiate yourself from the kiddie term, not from the script. Scripts, and, more generally, tools, are neutral. It is the maturity of your reactions, or lack thereof, which will mark you as a script kiddie or not. Despite what is usually believed on the subject, it has very little to do with technical skill; it is a matter of communication, of public relations. Be cool, don't whine, and you will never be a script kiddie.

You cannot, generically, reliably rebuild the base certificate from which such a report was generated (apparently with the OpenSSL command-line tool). For instance, you have the string contents of the Issuer and Subject names, but not the information about how they were encoded. You could use the signature as a discriminant for the certificates. You won't find a "normal" certificate with the exact same signature value (it is possible to build a fake certificate which contains the same signature, but you have to do it on purpose). If you know the public key of the certificate which was used to issue this specific certificate, then you could use the public key to do the first steps of the signature verification, yielding the SHA-1 hash of the "To Be Signed" (that's a feature of PKCS#1 RSA signatures: this is an algorithm "with recovery": from the signature and the public key, you can obtain a hash of the data which was signed). With that hash, you could test whether a putative reconstruction of the certificate is correct or not. But this is hard work. If you just want to check whether a given certificate is one of the certificates in the Mandiant report, extract the signature field (e.g. with OpenSSL) and look it up in the lists published by Mandiant.

There are 4 basic principles used in cryptography: confidentiality integrity authenticity non-repudiation. I will not go through the mathematical aspects involved, instead I will try to offer a more general description. Confidentiality is assured by the encrypting of data, integrity and authenticity are assured by a signed digest and non-repudiation is assured by the linking of the above operations to a digital certificate. The owner of the certificate is responsible for every action performed using that certificate. The best example I can think of right now for non-repudiation is that of the law of digital signature. This law states that a digital signature is in every way equivalent to the signature made by hand by a person. Usually, a trusted time source is also involved, so that the time of the signing is also trusted. All these ensure the fact that if you digitally sign the document, you cannot deny the signing, because of the fact you are the owner of the certificate and because there is a trusted time reference. It is the same as signing a contract for a loan at the bank. You cannot say you were not the one that agreed to the contract, because they have the proof (the handwritten signature).

One notion is called Perfect Forward Secrecy. This applies to situations where you encrypt data and decrypt it almost simultaneously, but you worry about an attacker who would later on obtain a copy of the decryption key. This is a restrictive model, but it applies to SSL connections: the server private key is long-lived (usually, it is stored in a local file) and thus subject to future theft; whereas there is no legitimate need to decrypt exchanged data at a future date. In the case of SSL, the solution relies on the "DHE" (Diffie-Hellman Ephemeral) cipher suites. Roughly speaking, client and server use a Diffie-Hellman key agreement, with fresh private exponents, to establish the session keys. The server private key (the one corresponding to the public key in the server certificate) is used only for signing (so that the server is duly authenticated by the client). Therefore, ulterior theft of the server private key does not allow the attacker to decrypt data which was exchanged beforehand. The Diffie-Hellman private exponents and the session key, being transient (linked to that session only), are never stored on a physical medium, and they are forgotten once the session is closed; therefore, they are much less susceptible to ulterior theft. Moore's law and overall increase in available computing power is not a big issue, because it is predictable: such computing power increases by a factor of less than 2 every year. Therefore, it is easy to oversize keys a bit to account for that factor: in the case of symmetric encryption, just add one key bit per year. This means that AES with a 192-bit key will be fine for at least one century, at least with regards to such technological advances. For RSA, Diffie-Hellman, Rabin-Williams or El-Gamal, aim at 8192-bit keys for the same protection level (384-bit key for elliptic curves). More worrisome are scientific advances, namely potential discovery of faster algorithms for, e.g., integer factorization. Such advances are much less predictable than technological advances; however, they also seem to happen quite rarely (the last big advance in factorization was the invention of the Number Field Sieve, and that was 20 years ago). The quantum computer is an unknown joker here: if it can ever be built, then it utterly destroys asymmetric cryptography (well, at least, the factorization-based and discrete-log based algorithms, including the elliptic curve variants; possibly, McElliece encryption may resist). Generally speaking, the biggest threat for long-term confidentiality of encrypted data is private key theft. When applicable, PFS really improves things by a fair margin. Worrying about Moore's law or quantum computing is very good news indeed: it means that you have already thwarted all easier attack vectors, which is no small achievement. Thinking that "encryption is an infallible lockbox" is not completely preposterous: if done properly, the encryption part itself will add negligible risks to what you must already face when it comes to storing a private key and keeping it safe while not losing it altogether.

From what I can tell, there have only been two serious public vulnerabilities in Steam. Markup injection (XSS) from steam:// links HTTPS man-in-the-middle attack Neither are current. I can't see any real risk. However, since Steam is completely unnecessary at work, it's a minor potential risk that could be avoided. Most likely, he's nit-picking because he doesn't think having Steam installed is appropriate at work, but he doesn't want to be the bad guy.

According to this article, the botnet uses known vulnerabilities against a variety of applications: The financially motivated attackers appeared to be targeting indiscriminately and went after domains that exposed a wide range of services to the internet. “Prowli exploits known vulnerabilities across WordPress, Joomla!, SMB, and even some DSL modems, so automated patching, along with continuous assessment and remediation, is critical to avoid these types of attacks," said Brajesh Goyal, CP of engineering, Cavirin. This explains why there is no specific CVE for this malware, since it does not use any one vulnerability and is not bundled with its own novel exploits. The best mitigation is outlined above. Automated patching will reduce the chance that this malware will infect your applications. The malware additionally exploits insecure configurations and SSH keys, so ensuring your system is adequately hardened and uses a proper password (or public key authentication) is also vital.

There's also the Pentest Standard

Yes, there are recent examples of attackers targetting ML systems in order to later evade detection. The term used for the study of this effect is "Adversarial Machine Learning". There are a number of papers: Berkeley, 2010 Berkeley, 2011 IEEE, 2011 One of the techniques discussed is the "boiling frog" technique. Named after the effect that one can boil a live frog without it jumping away to safety if the heat is turned up slowly. Attacks using this method attempt to mistrain the ML system by introducing anomalous stimuli at a very low anomaly factor, but with high frequency. Over time, the anomaly factor increases until the ML system learns to ignore truly anomalous stimuli, at which point the actual attack on the target systems begin. Because the ML systems have been trained to ignore it, the attack goes undetected. (The same technique has been used for years against people and security guards). This can be done with spam filters, IDS, UBA systems and Netflow analyzers. For instance: if you have gained the credentials of a valuable user, and you want to be able to log in as that user during a time when that user does not normally log in, you can start logging in using those credentials at times only slightly different from the user's normal pattern while not performing any unusual activity. Once you have seeded the logs with enough logins around the time when you want to perform your malicious activity, you can make your attempt and know that you will not trigger alarms for the anomalous login time. By seeding the logs with non-malicious activity, secondary and tertiary analysis of the activity will support the decision that the activity is not anomalous.

From what we understand, someone used the services provided by Google or another host to create an anonymous threat message and signed it with your son's name. Hosts such as Google usually have logs that indicate who they lent out the "temporary service" to at any given time. They would have the IP address or some other form of identifiable information associated with the entity who sent the message. It is highly unlikely that they are not maintaining any logs at all. Logs are maintained for cases such as this where improper use of services is observed. The real question is -- can you obtain this information from the host. The short answer is -- not really. Hosts such as Google are reluctant to share such details with just anyone due to privacy concerns. Your best bet is if the law enforcement involved requests these details from the host. They are more likely to comply with the request if law enforcement demands it for a valid reason. Unfortunately, there is not much you can do as an individual. Anonymity is the nature of many Internet services.

You are asking a couple different questions at once: how is ML implemented by a certain vendor, and how could it be implemented to be effective. Let's focus on the later. I have designed such algorithms for a major global financial institution, and I can give you the broad strokes. It's not too good to be true. Any security analyst will look at the logs, get to know how people operate in the company, and "get a sense" for what "normal" looks like. It's called 'baselining'. After some time, you "just know" when something looks fishy and you need to investigate because: The network goes quiet every Friday afternoon (for reasons that are obvious to any human in the office at the time) Network bandwidth gets maxed when the World Cup is on (streaming, not DDoS) That server always throws that error (a bad config no one knows how to fix) The user can never remember their passwords and always gets locked out We just turn a blind eye to that exec because everyone is afraid to tell them to behave more securely etc. Every other oddity, whether excessive errors or abnormally low errors (hey, why didn't that server throw that error?) deserves investigation. This used to be infosec bread and butter, but now goes under the fancy term of "threat hunting". But this baselining is easy to teach a computer. And you are correct, it all depends on the ability for the computer to understand what is 'normal'. It would be a crude approach to take the current state of the network and determine that that is 'normal'. You would train your algorithm to accept bad behaviour. You still do this as a factor, but you cannot depend on it entirely. You need another way of looking at the data. There are a couple ways to add another perspective. There are lots of fancy terms, but when I talk to non-algorithm people, I use the terms: 'weirdness' and 'badness'. Baselining the current state helps to determine 'weirdness'. If the network is already hacked, and the hacker is freely floating around the network, then that is not 'weird' for this network. It's 'bad', but not 'weird'. If we are good at determining 'weirdness', then we can see if a new hacker comes in, or if the current hacker changes tactics. We can augment the network baseline by determining what is 'weird' for user types by baselining subsets of the network. Devs act a certain way, execs act a certain way, cleaning staff act a certain way. If a cleaning staff account normally acts like an executive account in our current state, then we have something to investigate, even though it is 'normal' in the current state. So, this recursive baselining is one way to augment the ML perspective. Another way to add to the perspective is to define 'badness'. Things might be normal, but we can define that activity as categorically 'bad'. It might be 'normal' for this printer to be trying to log into every server in the DC, but we know that this is categorically 'bad'. So, if we can input these parameters into the algorithm (a lookup into a signatures table), we can expose the badness in our otherwise normal network activity. I first got into UBA after I ran a demo of a new UBA product about 3 years ago. I knew my network backwards and forwards, and instinctively knew what was normal and what wasn't. I looked into the UBA product as a backup for me and my small team to cover that skillset for when people were on holidays or if people left the team. I wasn't expecting much. But the product included this 'badness' perspective that instantly (within 2 hours) exposed badness in my network that I never knew was there even though I had baselined and was performing threat hunting daily. ML is not too good to be true. It's not perfect, but it is better than humans at breadth, speed, and consistency.

Whilst it is going to be debatable about whether these sources are reliable, there are a fair number of sources of information about data breaches, which generally touch on who they think is responsible. Verizon DBIR Secureworks Cybersecurity Threat insight Report EY Global Infomation Security Survey Basically there's loads of these reports from companies who deal in this space, which can be read to try and derive a picture of who's responsible for what.

Why you should never trust a public network: A brief overview of man-in-the-middle attacks. Why you should never trust a public network #2: Are you 100% sure that the convention center WiFi is really controlled by the convention center and not someone else who just made the SSID look like it's for the convention center? The name on the second one could probably use a focus group.

Very unlikely. I have never heard of an exploit in any cellphone operating system which can be exploited by taking a call from a malicious caller. If there were something like that, it would likely have made some news headlines, because it would be a huge vulnerability which would affect millions of end-users and would likely get widely exploited not just by criminals but also by juvenile pranksters. It's not possible to prove a negative, though. Maybe there is some obscure vulnerability I have never heard of. But that's really nothing you should worry about unless you are a target which is so valuable that you are worth burning a zero-day exploit on.