Christmas Came Early For Hackers: 2 Million Social Media Accounts Hacked, Big U.S. Bank Data Stolen

Hackers Stole 2M Facebook, Google Passwords: How to Protect Your Accounts

Dec. 5, 2013

Any time you logged into Facebook, Google, Twitter, or a host of other popular web services the past month, there may have been a hacker peering over your digital shoulder, sneaking a peek at your password.

The information security company Trustwave has revealed that the passwords to 2 million different accounts have been compromised. The malware program Pony forwarded the vast majority of the passwords to a central server in the Netherlands.

John Miller, security research manager at Trustwave, said that the hack wasn’t due to a flaw in any of those company’s servers. “It was the individual users’ computers that had the malware installed on their machine,” he told ABC News. He adds that the unnamed hackers were most likely motivated by profit. “These passwords were never publicly posted. We can’t say for sure, but [the hackers] were probably going to sell them.”

http://abcnews.go.com/Technology/hacker-group-stole-million-stolen-facebook-google-passwords/story?id=21109910

 

JP Morgan Chase Hacked: 465,000 Card  Users’ Data Gone

JPMorgan Chase, one of the world’s biggest Banks has recently announced that it was the victim of a cyber attack and warned round 465,000 of its holders of prepaid cash cards on the possible exposure of their personal information.

In the Security Breach that took place on the bank’s website www.ucard.chase.com in July, around 465,000 accounts are compromised i.e. 2% of the overall 25 million UCard users. JPMorgan confirmed that there is no risk for holders of debit cards, credit cards or prepaid Liquid cards.
 
They informed the law enforcement in September, and till now no information on how attackers have conducted the attack has been disclosed.

http://thehackernews.com/2013/12/JPMorgan-Chase-bank-card-hacked_5.html 

Advertisements

Senate Intelligence Committee Hearing: The NSA Wants Unlimited Citizen and Business Data in National Database

[NSA Director Keith] Alexander acknowledged that the NSA is interested in compiling the largest national database possible, and that there is no limit to the number of records that can be gathered. The storehouse holds billions of records, former officials have told The Washington Post.

Is it the goal of the NSA to collect the phone records of all Americans?” Udall asked.

I believe it is in the nation’s best interests to put all the phone records into a lockbox that we could search when the nation needs to do it, yes,” Alexander said.

 

The government has claimed the authority to gather the data under Section 215 of the USA Patriot Act, also known as the “business records” provision of the Foreign Intelligence Surveillance Act. The FISA court in 2006 agreed that the government could use that statute to order phone companies to hand over “all call detail records” daily to the NSA.

 

Asked by Udall if that statute gave NSA the authority to collect other data — such as utility bills — Deputy Attorney General James M. Cole offered a qualified answer. “It’s given them the authority to collect other bulk records if they can show that it is necessary to find something relevant to a foreign intelligence investigation of particular types. . . . It’s not just all bulk records. But it’s also not no business records. It’s all dependent on the purpose.”

 

 

[Sen. Ron Wyden (D-Oregon)], Udall and other lawmakers have introduced reform legislation that would, among other things, end the phone records collection, while allowing for a more limited program.

On Thursday, Wyden accused U.S. officials of not being more forthcoming about intelligence-collection programs.

“The leadership of your agencies built an intelligence-collection system that repeatedly deceived the American people,” he said. “Time and time again, the American people were told one thing about domestic surveillance in public forums while government agencies did something else in private.”

 

http://www.washingtonpost.com/world/national-security/nsa-leaks-extremely-damaging-national-intelligence-director-tells-senate-hearing/2013/09/26/a01b4e08-26d3-11e3-b75d-5b7f66349852_story.html

 

Wyden infamously showed down with Clapper earlier this year when he asked the lawmaker if the intelligence community collects information on millions of Americans. Clapper responded “not wittingly,” then later apologized to Committe Chairwoman Dianne Feinstein (D-California) for his “clearly erroneous” remark after Snowden’s leaks suggested otherwise only weeks later.

So that he would be prepared to answer, I sent the question to Director Clapper’s office a day in advance. After the hearing was over, my staff and I gave his office a chance to amend his answer,” Wyden told the Washington Post after the March meeting. “Now public hearings are needed to address the recent disclosures, and the American people have the right to expect straight answers from the intelligence leadership to the questions asked by their representatives.”

On Thursday, Alexander phrased questioning directed at Gen. Alexander in an attempt to determine if the NSA collected information from cell phone towers that could be used to locate customers. Alexander decline to provide a straight answer during an unclassified hearing.

 

If you’re responding to my question by not answering it because you think thats a classified matter, that is certainly your right,” said Wyden. “ We will continue to explore that because I believe that is something the American people deserve to know.”

 

http://rt.com/usa/fisa-hearing-nsa-surveillance-410/

Familiarize Yourself With Software Threat Modeling

Threat modeling has two distinct, but related, meanings in computer security. The first is a description of the security issues the designer cares about. This is the sense of the question, “What is the threat model for DNSSec?” In the second sense, a threat model is a description of a set of security aspects; that is, when looking at a piece of software (or any computer system), one can define a threat model by defining a set of possible attacks to consider. It is often useful to define many separate threat models for one computer system. Each model defines a narrow set of possible attacks to focus on. A threat model can help to assess the probability, the potential harm, the priority etc., of attacks, and thus help to minimize or eradicate the threats. More recently, threat modeling has become an integral part of Microsoft’s SDL (Security Development Lifecycle) process.[1] The two senses derive from common military uses in the United States and the United Kingdom.

Threat modeling is based on the notion that any system or organization has assets of value worth protecting, these assets have certain vulnerabilities, internal or external threats exploit these vulnerabilities in order to cause damage to the assets, and appropriate security countermeasures exist that mitigate the threats.

 There are at least three general approaches to threat modeling:

 Attacker-centric
Attacker-centric threat modeling starts with an attacker, and evaluates their goals, and how they might achieve them. Attacker’s motivations are often considered, for example, “The NSA wants to read this email,” or “Jon wants to copy this DVD and share it with his friends.” This approach usually starts from either entry points or assets.

Software-centric
Software-centric threat modeling (also called ‘system-centric,’ ‘design-centric,’ or ‘architecture-centric’) starts from the design of the system, and attempts to step through a model of the system, looking for types of attacks against each element of the model. This approach is used in threat modeling in Microsoft’s Security Development Lifecycle.

Asset-centric
Asset-centric threat modeling involves starting from assets entrusted to a system, such as a collection of sensitive personal information.

More at http://en.wikipedia.org/wiki/Threat_model

Introduction

Threat modeling is an approach for analyzing the security of an application. It is a structured approach that enables you to identify, quantify, and address the security risks associated with an application. Threat modeling is not an approach to reviewing code, but it does complement the security code review process. The inclusion of threat modeling 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 modeling 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. The concept of threat modeling is not new but there has been a clear mindset change in recent years. Modern threat modeling looks at a system from a potential attacker’s perspective, as opposed to a defender’s viewpoint. Microsoft have been strong advocates of the process over the past number of years. They have made threat modeling a core component of their SDLC, which they claim to be one of the reasons for the increased security of their products in recent years.

When source code analysis is performed outside the SDLC, such as on existing applications, the results of the threat modeling help in reducing the complexity of the source code analysis by promoting an in-depth first approach vs. breadth first approach. Instead of reviewing all source code with equal focus, you can prioritize the security code review of components whose threat modeling has ranked with high risk threats.

The threat modeling process can be decomposed into 3 high level steps:

Step 1: Decompose the Application. The first step in the threat modeling process is concerned with gaining an understanding of the application and how it interacts with external entities. This involves creating use-cases to understand how the application is used, identifying entry points to see where a potential attacker could interact with the application, identifying assets i.e. items/areas that the attacker would be interested in, and identifying trust levels which represent the access rights that the application will grant to external entities. This information is documented in the Threat Model document and it is also used to produce data flow diagrams (DFDs) for the application. The DFDs show the different paths through the system, highlighting the privilege boundaries.

Step 2: Determine and rank threats. Critical to the identification of threats is using a threat categorization methodology. A threat categorization such as STRIDE can be used, or the Application Security Frame (ASF) that defines threat categories such as Auditing & Logging, Authentication, Authorization, Configuration Management, Data Protection in Storage and Transit, Data Validation, Exception Management. The goal of the threat categorization is to help identify threats both from the attacker (STRIDE) and the defensive perspective (ASF). DFDs produced in step 1 help to identify the potential threat targets from the attacker’s perspective, such as data sources, processes, data flows, and interactions with users. These threats can be identified further as the roots for threat trees; there is one tree for each threat goal. From the defensive perspective, ASF categorization helps to identify the threats as weaknesses of security controls for such threats. Common threat-lists with examples can help in the identification of such threats. Use and abuse cases can illustrate how existing protective measures could be bypassed, or where a lack of such protection exists. The determination of the security risk for each threat can be determined using a value-based risk model such as DREAD or a less subjective qualitative risk model based upon general risk factors (e.g. likelihood and impact).

Step 3: Determine countermeasures and mitigation. A lack of protection against a threat might indicate a vulnerability whose risk exposure could be mitigated with the implementation of a countermeasure. Such countermeasures can be identified using threat-countermeasure mapping lists. Once a risk ranking is assigned to the threats, it is possible to sort threats from the highest to the lowest risk, and prioritize the mitigation effort, such as by responding to such threats by applying the identified countermeasures. The risk mitigation strategy might involve evaluating these threats from the business impact that they pose and reducing the risk. Other options might include taking the risk, assuming the business impact is acceptable because of compensating controls, informing the user of the threat, removing the risk posed by the threat completely, or the least preferable option, that is, to do nothing.

More at https://www.owasp.org/index.php/Application_Threat_Modeling

 Computer insecurity is the concept that a computer system is always vulnerable to attack, and that this fact creates a constant battle between those looking to improve security and those looking to circumvent security.

 “Several computer security consulting firms produce estimates of total worldwide losses attributable to virus and worm attacks and to hostile digital acts in general. The 2003 loss estimates by these firms range from $13 billion (worms and viruses only) to $226 billion (for all forms of covert attacks). The reliability of these estimates is often challenged; the underlying methodology is basically anecdotal.

 A state of computer “security” is the conceptual ideal, attained by the use of the three processes:

1. Prevention
2. Detection
3. Response

User account access controls and cryptography can protect systems files and data, respectively.
Firewalls are by far the most common prevention systems from a network security perspective as they can (if properly configured) shield access to internal network services, and block certain kinds of attacks through packet filtering.
Intrusion Detection Systems (IDSs) are designed to detect network attacks in progress and assist in post-attack forensics, while audit trails and logs serve a similar function for individual systems.
“Response” is necessarily defined by the assessed security requirements of an individual system and may cover the range from simple upgrade of protections to notification of legal authorities, counter-attacks, and the like. In some special cases, a complete destruction of the compromised system is favored, as it may happen that not all the compromised resources are detected.
Today, computer security comprises mainly “preventive” measures, like firewalls or an Exit Procedure. A firewall can be defined as a way of filtering network data between a host or a network and another network, such as the Internet, and can be implemented as software running on the machine, hooking into the network stack (or, in the case of most UNIX-based operating systems such as Linux, built into the operating system kernel) to provide realtime filtering and blocking. Another implementation is a so-called physical firewall which consists of a separate machine filtering network traffic. Firewalls are common amongst machines that are permanently connected to the Internet. However, relatively few organisations maintain computer systems with effective detection systems, and fewer still have organised response mechanisms in place. As result, as Reuters points out: “Companies for the first time report they are losing more through electronic theft of data than physical stealing of assets”.[5] The primary obstacle to effective eradication of cyber crime could be traced to excessive reliance on firewalls and other automated “detection” systems. Yet it is basic evidence gathering by using Packet Capture Appliances that puts criminals behind bars.

Computer code is regarded by some as a form of mathematics. It is theoretically possible to prove the correctness of certain classes of computer programs, though the feasibility of actually achieving this in large-scale practical systems is regarded as small by some with practical experience in the industry — see Bruce Schneier et al.

It’s also possible to protect messages in transit (i.e., communications) by means of cryptography. One method of encryption — the one-time pad — is unbreakable when correctly used. This method was used by the Soviet Union during the Cold War, though flaws in their implementation allowed some cryptanalysis (See Venona Project). The method uses a matching pair of key-codes, securely distributed, which are used once-and-only-once to encode and decode a single message. For transmitted computer encryption this method is difficult to use properly (securely), and highly inconvenient as well. Other methods of encryption, while breakable in theory, are often virtually impossible to directly break by any means publicly known today. Breaking them requires some non-cryptographic input, such as a stolen key, stolen plaintext (at either end of the transmission), or some other extra cryptanalytic information.

Social engineering and direct computer access (physical) attacks can only be prevented by non-computer means, which can be difficult to enforce, relative to the sensitivity of the information. Even in a highly disciplined environment, such as in military organizations, social engineering attacks can still be difficult to foresee and prevent.

In practice, only a small fraction of computer program code is mathematically proven, or even goes through comprehensive information technology audits or inexpensive but extremely valuable computer security audits, so it’s usually possible for a determined hacker to read, copy, alter or destroy data in well secured computers, albeit at the cost of great time and resources. Few attackers would audit applications for vulnerabilities just to attack a single specific system. It is possible to reduce an attacker’s chances by keeping systems up to date, using a security scanner or/and hiring competent people responsible for security. The effects of data loss/damage can be reduced by careful backing up and insurance.

 More at http://en.wikipedia.org/wiki/Computer_insecurity

Attack trees are conceptual diagrams showing how an asset, or target, might be attacked. Attack trees have been used in a variety of applications. In the field of information technology, they have been used to describe threats on computer systems and possible attacks to realize those threats. However, their use is not restricted to the analysis of conventional information systems. They are widely used in the fields of defense and aerospace for the analysis of threats against tamper resistant electronics systems (e.g., avionics on military aircraft).[1] Attack trees are increasingly being applied to computer control systems (especially relating to the electric power grid ).[2] Attack trees have also been used to understand threats to physical systems.

Some of the earliest descriptions of attack trees are found in papers and articles by Bruce Schneier,[3] CTO of Counterpane Internet Security. Schneier was clearly involved in the development of attack tree concepts and was instrumental in publicizing them. However, the attributions in some of the early publicly available papers on attack trees[4] also suggest the involvement of the National Security Agency in the initial development.

Attack trees are very similar, if not identical, to threat trees. Threat trees were discussed in 1994 by Edward Amoroso

 Attack trees are multi-leveled diagrams consisting of one root, leaves, and children. From the bottom up, child nodes are conditions which must be satisfied to make the direct parent node true; when the root is satisfied, the attack is complete. Each node may be satisfied only by its direct child nodes.

A node may be the child of another node; in such a case, it becomes logical that multiple steps must be taken to carry out an attack. For example, consider classroom computers which are secured to the desks. To steal one, the securing cable must be cut or the lock unlocked. The lock may be unlocked by picking or by obtaining the key. The key may be obtained by threatening a key holder, bribing a keyholder, or taking it from where it is stored (e.g. under a mousemat). Thus a four level attack tree can be drawn, of which one path is (Bribe Keyholder,Obtain Key,Unlock Lock,Steal Computer).

Note also that an attack described.

 More at http://en.wikipedia.org/wiki/Attack_tree

Factor analysis of information risk (FAIR for short) is a taxonomy of the factors that contribute to risk and how they affect each other. It is primarily concerned with establishing accurate probabilities for the frequency and magnitude of loss events. It is not, per se, a “cookbook” that describes how to perform an enterprise (or individual) risk assessment

The unanswered challenge, however, is that without a solid understanding of what risk is, what the factors are that drive risk, and without a standard nomenclature, we can’t be consistent or truly effective in using any method. FAIR seeks to provide this foundation, as well as a framework for performing risk analyses. Much of the FAIR framework can be used to strengthen, rather than replace, existing risk analysis processes like those mentioned above

As a standards body, The Open Group aims to evangelize the use of FAIR within the context of these risk assessment or management frameworks. In doing so, The Open Group becomes not just a group offering yet another risk assessment framework, but a standards body which solves the difficult problem of developing consistent, defensible statements concerning risk

FAIR underlines that risk is an uncertain event and one should not focus on what is possible, but on how probable is a given event. This probabilistic approach is applied to every factor that is analysed. The risk is the probability of a loss tied to an asset.

Asset
An asset’s loss potential stems from the value it represents and/or the liability it introduces to an organization.[3] For example, customer information provides value through its role in generating revenue for a commercial organization. That same information also can introduce liability to the organization if a legal duty exists to protect it, or if customers have an expectation that the information about them will be appropriately protected.

FAIR defines six kind of loss:[3]

1. Productivity – a reduction of the organization to effectively produce goods or services in order to generate value
2. Response – the resources spent while acting following an adverse event
3. Replacement – the expense to substitute/repair an affected asset
4. Fines and judgements (F/J) – the cost of the overall legal procedure deriving from the adverse event
5. Competitive advantage (CA)- missed opportunities due to the security incident
6. Reputation – missed opportunities or sales due to the diminishing corporate image following the event

FAIR defines value/liability as:[3]

1. Criticality – the impact on the organization productivity
2. Cost – the bare cost of the asset, the cost of replacing a compromised asset
3. Sensitivity – the cost associated to the disclosure of the information, further divided into:

   1. Embarrassment – the disclosure states the inappropriate behaviour of the management of the company
   2. Competitive advantage – the loss of competitive advantage tied to the disclosure
   3. Legal/regulatory – the cost associated with the possible law violations
   4. General – other losses tied to the sensitivity of data

Threat
Threat agents can be grouped by Threat Communities, subsets of the overall threat agent population that share key characteristics. It’s important to define precisely threat communities in order to effectively evaluate impact (loss magnitude).

Threat agents can act differently on an asset:[3]

Access – read the data without proper authorization
Misuse – use the asset without authorization and or differently form the intended usage
Disclose – the agent let other people to access the data
Modify – change the asset (data or configuration modification)
Deny access – the threat agent do not let the legitimate intended users to access the asset

This actions can affect differently various asset: the impact is different along with the characteristics of the asset and its usage. Some assets have high criticality and low sensitivity: deny access has a much higher impact than disclosure on them. Vice versa high sensitivity data can have low productivity impact while not available, but huge embarrassment and legal impact if disclosed: former patient health data availability do not affect an healthcare organization productivity but can cost millions dollars if disclosed. [4] A single event can involve different assets: a [laptop theft] has an impact on the availability of the laptop itself but can lead to the potential disclosure of the information stored on it.

The point is that it’s the combination of the asset and type of action against the asset that determines the fundamental nature and degree of loss.

Important aspects to be considered are the agent motive and the affected asset characteristics.

 More at http://en.wikipedia.org/wiki/Factor_Analysis_of_Information_Risk

Jim Bird, SWReflections Blog: What is Important in Secure Software Design?

There are many basic architectural and design mistakes that can compromise the security of a system:

  1. Missing something important in security features like access control or auditing, privacy and compliance requirements;
  2. Technical mistakes in understanding and implementing defence-against-the-dark-arts security stuff like crypto, managing secrets and session management (you didn’t know enough to do something or to do it right);
  3. Misunderstanding architectural responsibilities and trust zones, like relying on client-side validation, or “I thought that the data was already sanitized”;
  4. Leaving the attack surface bigger than it has to be – because most developers don’t understand what a system’s attack surface is, or know that they need to watch out when they change it;
  5. Allowing access by default, so when an error happens or somebody forgets to add the right check in the right place, the doors and windows are left open and the bad guys can walk right in;
  6. Choosing an insecure development platform or technology stack or framework or API and inheriting somebody else’s design and coding mistakes;
  7. Making stupid mistakes in business workflows that allow attackers to bypass checks and limits and steal money or steal information.

 

Learning about Secure Software Design

If you want to build a secure system, you need to understand secure design.

Read more at http://swreflections.blogspot.com/2013/06/what-is-important-in-secure-software.html

Exactly What is ‘Secure by Design’ in Software Engineering?

Secure by design, in software engineering, means that the software has been designed from the ground up to be secure. Malicious practices are taken for granted and care is taken to minimize impact when a security vulnerability is discovered or on invalid user input.

Generally, designs that work well do not rely on being secret. It is not mandatory, but proper security usually means that everyone is allowed to know and understand the design because it is secure. This has the advantage that many people are looking at the code, and this improves the odds that any flaws will be found sooner (Linus’ law). Of course, attackers can also obtain the code, which makes it easier for them to find vulnerabilities as well.

Also, it is very important that everything works with the least amount of privileges possible (principle of least privilege). For example a Web server that runs as the administrative user (root or admin) can have the privilege to remove files and users that do not belong to itself. Thus, a flaw in that program could put the entire system at risk. On the other hand, a Web server that runs inside an isolated environment and only has the privileges for required network and filesystem functions, cannot compromise the system it runs on unless the security around it is in itself also flawed.

Read more at http://en.wikipedia.org/wiki/Security_by_design 

SafeCode.org: Software Security Guidance for Agile Practitioners

Wakefield, Ma. – July 17, 2012 – The Software Assurance Forum for Excellence in Code (SAFECode), a non-profit organization exclusively dedicated to increasing trust in information and communications technology products and services through the advancement of effective software assurance methods, today released “Practical Security Stories and Security Tasks for Agile Development Environments.” This new paper provides practical software security guidance to Agile practitioners in the form of security-focused stories and security tasks they can easily integrate into their Agile-based development environments. The paper is the outcome of a collaboration of SAFECode members working to simplify the process for addressing security assurance tasks as part of an Agile development methodology.

“A number of SAFECode members recognized the natural tension between the dynamic nature of Agile development methodologies and more formalized processes for secure software development. After working on various ways we could better insert the most important elements of the security process into a standard Agile development process, we came up with this relatively simple approach of presenting security-focused stories with associated security tasks, alongside operational security tasks and those that most often require the support of a security expert,” said Vishal Asthana, a lead author of the paper and Senior Principle Software Engineer, Product Security Group, Symantec Corp. “A small group of us have been piloting the approach within our own teams and have seen enough early value that we felt it would be beneficial to share the approach with the broader community.”

In an Agile development process, necessary changes are incorporated in a dynamic fashion. Cycles/sprints are very short, usually no more than two to four weeks, making it extremely difficult for software development teams to comply with long lists of security assurance tasks. This paper addresses this challenge by translating secure development practices into a language and format that Agile practitioners can more readily act upon as part of a standard Agile methodology. To further simplify things, the recommended security tasks are broken down by roles, including architects, developers and testers, and separately lists the tasks that most often require specialized skills from security experts.

http://www.safecode.org/news.php#press_release_agile

(ISC)2: The Ten Best Practices for Secure Software Development

1. Protect the Brand Your Customers Trust

2. Know Your Business and Support it with Secure Solutions

3. Understand the Technology of the Software

4. Ensure Compliance to Governance, Regulations, and Privacy

5. Know the Basic Tenets of Software Security

6. Ensure the Protection of Sensitive Information

7. Design Software with Secure Features

8. Develop Software with Secure Features

9. Deploy Software with Secure Features

10. Educate Yourself and Others on How to Build Secure Software

https://www.isc2.org/uploadedFiles/(ISC)2_Public_Content/Certification_Programs/CSSLP/ISC2_WPIV.pdf