HackersgymHackersgym
Security Evaluation Methodologies
security evaluation The examination of a system to determine its degree of compliance with a stated security model, security standard, or specification. The evaluation may be conducted (a) by analyzing the detailed design, especially of the software, often using verification and validation, (b) by observing the functional behavior of the system, or (c) by attempting to penetrate the system using techniques available to an “attacker”.
The following topics will be covered in details:
Threat modeling
Threat modeling is a method of optimizing network security by locating vulnerabilities, identifying objectives, and developing countermeasures to either prevent or mitigate the effects of cyber-attacks against the system.
Objectives of Threat Modeling
Threat modeling is a family of activities for improving security by identifying threats, and then defining countermeasures to prevent, or mitigate the effects of, threats to the system. A threat is a potential or actual undesirable event that may be malicious (such as DoS attack) or incidental (failure of a Storage Device). Threat modeling is a planned activity for identifying and assessing application threats and vulnerabilities.
How does threat modeling work?
Threat modeling works by identifying the types of threat agents that cause harm to an application or computer system. It adopts the perspective of malicious hackers to see how much damage they could do. When conducting threat modeling, organizations perform a thorough analysis of the software architecture, business context, and other artifacts (e.g., functional specifications, user documentation). This process enables a deeper understanding and discovery of important aspects of the system. Typically, organizations conduct threat modeling during the design stage (but it can occur at other stages) of a new application to help developers find vulnerabilities and become aware of the security implications of their design, code, and configuration decisions.
Threat Modeling Across the Lifecycle
Threat modeling is best applied continuously throughout a software development project. The process is essentially the same at different levels of abstraction, although the information gets more and more granular throughout the lifecycle. Ideally, a high-level threat model should be defined early on in the concept or planning phase, and then refined throughout the lifecycle. As more details are added to the system, new attack vectors are created and exposed. The ongoing threat modeling process should examine, diagnose, and address these threats.
It is a natural part of refining a system for new threats to be exposed. For example, when you select a particular technology – such as Java for example – you take on the responsibility of identifying the new threats that are created by that choice. Even implementation choices such as using regular expressions for validation can introduce potential new threats to deal with.
Updating threat models is advisable after events such as:
A new feature is released
Security incident occurs
Architectural or infrastructure changes
Advantages of threat modeling
When performed correctly, threat modeling can provide a clear line of sight across a software project, helping to justify security efforts. The threat modeling process helps an organization document knowable security threats to an application and make rational decisions about how to address them. Otherwise, decision-makers could act rashly based on scant or no supporting evidence.
Overall, a well-documented threat model provides assurances that are useful in explaining and defending the security posture of an application or computer system. And when the development organization is serious about security, threat modeling is the most effective way to do the following:
Misconceptions of threat modeling
As a security process, threat modeling is subject to several misconceptions. Some people believe threat modeling is only a design-stage activity, some see it as an optional exercise for which penetration testing or code review can substitute, and some think the process is simply too complicated. The following should help dispel some of these misconceptions:
Penetration testing and code reviews can’t substitute for threat modeling. Penetration testing and secure code review are two activities that are effective for finding bugs in code. However, security assessments (e.g., threat modeling) are better at uncovering design flaws.
There’s a good reason to conduct a threat model after deployment. Understanding the issues in the current deployment influences future security architecture strategy, and monitoring weaknesses allows for faster and more effective remediation. Without understanding the potential threats an application faces, you can’t ensure that you’re addressing all risks.
Threat modeling isn’t that complicated. Many developers are intimidated by the idea of threat modeling. At first glance, it can seem daunting. However, if you break up the tasks into workable steps, performing a threat model on a simple web application—or even a complex architecture—becomes systematic. The key is to start with basic best practices.
Information Leakage Incidents and Evaluation of Security Level
Corporations’ information leakage incidents have different characteristics from existing privacy issues. From the perspective of a corporation, internal technological information and privacy differ in terms of the relevant security activities, both before the occurrence of security incidents and activities and after the incident and the impacts on the organization.
Prior to conducting security management, the distinguishing of information assets and graded security activities is performed according to level and private information handled by the corporation, including the private information of employees, customers and vendors, which are all graded as a single level. However, in the case of internal technology information, patents, intellectual property rights, trade secrets, etc., are classified as multi-leveled, which results in different security activities being conducted according to each level.
After the occurrence of a security incident, impacts on the organization also differ in terms of privacy and internal technological information.
In the case of a privacy leakage, the extent of the effects on the business is relatively small.
Six Steps to Successful Threat Modeling:
Table 1 summarizes the differences
between internal and external security attacks on organizations
Threat modeling methodologies for IT purposes
Conceptually, a threat modeling practice flows from a methodology. Numerous threat modeling methodologies are available for implementation. Typically, threat modeling has been implemented using one of four approaches independently, asset-centric, attacker-centric, and software-centric. Based on volume of published online content, the methodologies discussed below are the most well known.
STRIDE methodology
The STRIDE approach to threat modeling was introduced in 1999 at Microsoft, providing a mnemonic for developers to find 'threats to our products'.[9] STRIDE, Patterns and Practices, and Asset/entry point were amongst the threat modeling approaches developed and published by Microsoft. References to "the" Microsoft methodology commonly mean STRIDE and Data Flow Diagrams.
P.A.S.T.A.
The Process for Attack Simulation and Threat Analysis (PASTA) is a seven-step, risk-centric methodology.[10] It provides a seven-step process for aligning business objectives and technical requirements, taking into account compliance issues and business analysis. The intent of the method is to provide a dynamic threat identification, enumeration, and scoring process. Once the threat model is completed, security subject matter experts develop a detailed analysis of the identified threats. Finally, appropriate security controls can be enumerated. This methodology is intended to provide an attacker-centric view of the application and infrastructure from which defenders can develop an asset-centric mitigation strategy.
Trike
The focus of the Trike methodology[11] is using threat models as a risk-management tool. Within this framework, threat models are used to satisfy the security auditing process. Threat models are based on a “requirements model.” The requirements model establishes the stakeholder-defined “acceptable” level of risk assigned to each asset class. Analysis of the requirements model yields a threat model from which threats are enumerated and assigned risk values. The completed threat model is used to construct a risk model based on asset, roles, actions, and calculated risk exposure.
VAST
The Visual, Agile and Simple Threat (VAST) methodology,[12] is based on ThreatModeler, a commercial automated threat-modeling platform. VAST requires creating two types of models: application threat models and operational threat models. Application threat models use process-flow diagrams, representing the architectural point of view. Operational threat models are created from an attacker point of view based on DFDs. This approach allows for the integration of VAST into the organization's development and DevOps lifecycles.[13]
Best Practices for Evaluating Cybersecurity Tools
1.Take risk based approach.
As you evaluate tools, take a step back and ask yourself if the control being evaluated will truly help your organization reduce risk. If it doesn’t, than your time and budget may be better spent elsewhere. While this is not a rule that is set in stone, it is a good one to review as you start your evaluation.
2.Define your requirements.
You would be surprised how many times this does not happen. Take an hour and map out your high level requirements for an optimal solution to meet your use cases. Make sure to classify any “must-have” vs. “nice to have” features. Also, be sure you align whatever technology you’re evaluating into how it fits within and integrates into your current tech stack, as well as what your team can actually support. Keep in mind any involvement needed from server teams, network teams, helpdesk, etc.—not just the security team. This exercise can quickly help you eliminate non-qualified solutions from your short list. And the less time you spend on vendor demos, the faster you can get to actual solution testing.
3.Have a test plan.
This is something else that is missed many times. If you do not have a documented test plan, it is difficult to truly compare solutions. Most vendors have POC evaluation criteria that can be leveraged as a starting point, and solution providers like GuidePoint Security can share additional examples. As part of this process, you’ll want to follow a consistent methodology so that you can quickly score solutions side by side.
4.Limit the scope.
Defining requirements should help you limit the number of solutions you test. We have seen clients test 7-8 solutions at times and while this may work for larger enterprise clients with innovation centers and extensive lab environments, many times there are diminishing returns for the more solutions tested. As a rule of thumb we generally recommend that clients perform deep dive testing of no more than 2-3 solutions after a detailed requirements review.
5.Leverage your resources.
Find and use existing comparison documents where possible to speed up this effort. Analyst reports can help here, but they aren’t bulletproof. Work with your partners and industry peers to see what they have on hand. No need to recreate the wheel. Also, push vendors to do deep dive demos tailored to your use cases rather than unnecessary POCs.
6.Pilots are better than POCs.
Where possible, test in controlled, isolated areas of production rather that solely in a lab. Lab POC testing is fine, but many times this limits the amount of actual integrations you can test, such as Active Directory Integration, SIEM, architecture integration, etc. Again, controlled and isolated is the key phrase when testing in production. Don’t take your network down testing a new tool.
Importance of Security Assessments
Many organizations’ cyber security systems are reactive, responding to a system crash, a hack, or a data breach. A better approach to IT infrastructural security is being proactive so that threats can be eliminated and loopholes blocked before damage can be done to the system.A security assessment involves analyzing the technology used in your organization or business, looking for any weaknesses that could be exploited by attackers, and providing recommendations about how you can improve your cyber security.
In the first phase, a focus is placed on going through your current security system to better understand the types of software and devices your business uses as well as their usage on a day-to-day basis. The second phase involves examining your current system. In this step, any weaknesses in your security system are identified and fixed. In the final phase of the security assessment, the fixes are tested to ensure that everything is in the right place. In case there is a need for any improvement, the process starts back from phase two and once the assessment is completed, you, as the business owner or manager, will be given a detailed explanation of what was changed and why it was changed. You will also be enlightened on what needs to be done in the future.
Why Do You Need a Security Assessment?
The decision to conduct a security assessment for your business should be justified by weighing the benefits. To help you determine if conducting a security assessment is a good move for your business, here are four top benefits that a security assessment offers:
Bolstered Security
The most obvious advantage of security assessments is that it bolsters the security of your organization or business. A thorough security assessment will examine your system and find weaknesses that you may not have even known existed. Followed by fixing such problems and blocking any loophole. Not only can this procedure prevent your proprietary information from landing in bad hands, but it can also prevent you from losing all your data in case of system breakdown.
Many threats such as ransom-ware and viruses can result in a complete breakdown of your IT infrastructure, thereby crippling your business especially if it relies heavily on technology to run – which most organizations and businesses do these days. Regular security assessments will help prevent disasters such as these from happening, thereby saving you a fortune.
You Will Learn to Take Preventative Measures
As a security assessment is being performed, you will find out where your weaknesses lie and how you can address them. You will also be enlightened on the preventative measures you should put in place. It is always wise to prevent an attack than waiting to react when a vulnerability is exploited. Forecasting where weakness may arise in the future and preparing for it now can save you a lot.
Increased Awareness
Routine security assessments help enlighten you and your staff on newer ways of safeguarding sensitive data and information. Sometimes, online habits of your employees can pose a security threat to your business. Your security assessment team can enlighten them on simple things that they can pay attention to when surfing online. A little extra attention is a positive thing and can help you detect a problem early before it becomes full blown.
It Ensures Consistency
Different systems and applications in your business may be secured in different ways. This inconsistency can bring confusion to your IT staff and can decrease your security in business. With a security assessment, all your applications and systems are updated to follow the same security protocols and use the same security software. This creates a consistent, reliable approach to security across the business and increases both effectiveness and efficiency of your IT department.
Getting a security assessment for your organization or business is a straightforward and simple process, and you can choose your level of involvement in the process. The process is non-disruptive and can be conducted without altering the day-to-day operations of your business. It doesn’t interfere with how your employees execute their duties unless it involves in-depth examinations and improvements. Besides, a thorough security assessment is affordable, making it justifiable for even small and medium-sized organizations and businesses.
Interested in setting up a security assessment for your company? Schedule a FREE no obligation Network & Security Audit with us today. Click Here to schedule your technology health check.
Enter Attack Trees
Attack trees allow threats against system security to be modeled concisely in an easy to understand graphical format. The effectiveness of cybersecurity, network security, banking system security, installation and personnel security may all be modeled using attack trees.
Attack trees provide a formal, methodical way of describing the security of systems, based on varying attacks. Basically, you represent attacks against a system in a tree structure, with the goal as the root node and different ways of achieving that goal as leaf nodes.
Figure 1: Attack Nodes
Figure 1, for instance, is a simple attack tree against a physical safe. The goal is opening the safe. To open the safe, attackers can pick the lock, learn the combination, cut open the safe, or install the safe improperly so that they can easily open it later. To learn the combination, they either have to find the combination written down or get the combination from the safe owner. And so on. Each node becomes a subgoal, and children of that node are ways to achieve that subgoal.
Common Criteria Software Security Evaluation
The Common Criteria for Information Technology Security Evaluation, abbreviated as “Common Criteria” or “CC,” is an internationally recognized set of information security standards. It is also internationally known as ISO 15408. The CC standards codify a language for defining and evaluating information technology security systems and products. The CC objectives are intended to:
Provide a consistent, international standard against which security functionality is tested
Improve product security by uncovering vulnerabilities before a product (or a new version) is released
Provide customers with third-party assurance, confirming that the product will function and perform per the vendor's specifications
The framework provided by the Common Criteria allows government agencies and other groups to define sets of specific Functional and Assurance requirements, called Protection Profiles. The standard also provides accredited evaluation laboratories, which are certified by their local governmental entity, with procedures for evaluating the products or systems against the specified requirements.
Common Criteria evaluations are measured by evaluation assurance level (EAL), ranging from the lowest, EAL 1, to the highest, EAL 7. Currently, 22 countries participate in a reciprocal recognition agreement that allows a product validated in any participating country to be accepted by any other participating country, up to EAL 4. The current version of the standard, v2.2, is in the process of being updated to v3.1, which greatly simplifies and clarifies the overall structure of the standard. Clarifications will include reorganization of the requirements to eliminate duplicated areas and create consistency within the documents that make up the Common Criteria standard.
Common Criteria can be applied to hardware, software, or firmware products individually or as part of a larger system. The evaluation does not necessarily focus on the product alone, but rather on its security components as outlined by the vendor in a Security Target (ST) document. Vendors use a Target of Evaluation (TOE) to define a boundary around the portions of the product that will be included in the evaluation. Accredited, independent laboratories then test against vendor-specified claims and send results to the appropriate evaluating body.
Common Criteria evaluations are costly and time consuming. They typically take significantly longer and cost significantly more than validations of the same products under FIPS 140-2 as described below. This is partially due to the scope of Common Criteria evaluation efforts and partially due to the complexity of the CC language and evaluation methodologies. Expertise in Common Criteria terminology and methodologies becomes a pre-requisite for efficient or even successful CC evaluation efforts.
WHAT IS SECURITY ASSESSMENT?
A security assessment is the starting point for an organisation to establish their cyber security policy and combat security threats. It provides a view of the organisation’s cyber security posture at a point in time. It helps to locate the resources that your business pays for but is either under-utilising or over-utilising them.
For instance, a security audit can help uncover several inefficient setups that should be fixed in order to strengthen IT infrastructure and provide peace of mind.
6 REASONS, WHY YOU SHOULD CONDUCT REGULAR SECURITY ASSESSMENTS
IMPORTANCE OF SECURITY RISK ASSESSMENTS
Ensure Security of Data
One of the first things that come to mind on hearing about a cyber-attack is the security of data. Conducting regular security assessments helps ensure the safety and security of crucial data by implementing safeguards and measures.
It tests whether the methods employed to protect data are effectively safeguarding the data from all potential points of attack or not.
The healthcare industry is a good example. Data generated in healthcare, like patient information, medical conditions and illnesses, prescriptions and drugs, medical procedures, etc., are extremely sensitive in nature.
Any such data that a healthcare organisation stores, transfers, processes, or maintains, should be adequately protected. The data can reside within, any or all, database, servers, connected medical equipment, mobile devices, and cloud storage. All these platforms need to be secured in the best way possible.
Safeguarding measures include risk assessments, blocking the network, and in extreme cases, system shutdowns. They help prevent medical fraud and hacking of personal information of the patients.
A range of services are employed to ensure data security, including internal and external penetration testing, database security assessment, and web application testing.
Reallocate Resources and Identify Training Needs
You may not know what resources your company is underusing or overusing until you conduct a security assessment. For identified vulnerabilities, a security assessment indicates and helps organise the resources needed on priority. On the other hand, with an audit, a security assessment also helps cut down on those resources and tools that your company doesn’t need but was continuing to pay.
This goes a long way in reducing unnecessary expenses and freeing up your IT budget to invest in other critical aspects. Apart from this, security assessments also provide a platform to identify the training needs for employees.
Gaps between employee education and operations, and company standards can be efficiently identified and plugged with strategies for training and upskilling.
Get Equipped With Cybersecurity Policies and Procedures
A data breach can cause substantial loss to an organisation, and lead to legal troubles, financial loss and tarnish the company’s image. Not all businesses are able to recover from it.
Thus, it does not hurt to establish robust policies and procedures to strengthen the overall security posture of your organisation. To do this effectively, begin with a strategic security assessment and have industry experts review it.
Generally, below topics should be covered in cyber security policies and procedures.
Another important reason for conducting regular security assessments is to develop contingency plans for disaster recovery, strengthen the overall security plan and keep them up to date as the cyber threat environment evolves.
Whether your organisation’s data is stored on-premise, in the cloud, or both, a security assessment helps indicate crucial information needed to be backed up.
It begins with prioritising the company’s most valuable assets; the main aim after a disaster situation is to re-establish primary business operations as soon as possible.
In case of emergencies and breaches in the organisation’s information security, the contingency plan developed through security assessment will provide the guidelines for data and services restoration from backups and for other activities.
Security threats can be both external (hackers attempting to break into organisation’s systems) and internal (an angry employee wanting to cause damage). or malware that may have entered your system looking for crucial information.
Periodical security assessments expose vulnerabilities and security risks associated with the complete IT landscape. The organisation can be prepared and equipped with necessary tools and resources to defend against external attacks if they are aware about the vulnerabilities and not simply defending blindly.
Security assessment will also include classification of discovered vulnerabilities as per severity of impact and likelihood, and remediation guidelines.
Security Compliance
Security compliance is also a big reason why security assessment is a must for an organisation. Security assessment helps evaluate and score the company’s information security posture against globally recognised standards and implementation of best practices. One can consider it as a gap assessment that identifies what is required to meet the set standards.
For instance, common security compliance for the healthcare industry is the HIPAA (Health Insurance Portability and Accountability Act), which applies to all healthcare providers and related services like insurance companies.
Under this Act, these organisations are required to reveal their data storage and data sharing practices and be subjected for scrutiny. Another example is PCI DSS (Payment Card Industry Data Security Standard) that covers entities dealing in cardholder data. Any business that stores, processes, or transfers cardholder data has to comply with PCI DSS.
We have discussed at length, the reasons for making the case for periodical and timely cybersecurity assessments. If you are planning for a full security assessment or want to know more about security practices, please reach us at Secure Triad.
We are a penetration testing services company, and we can conduct unbiased and independent security risk assessments for your business. We are committed to ensuring your business remains secured against evolving cyber threats.
Social Engineering
Social engineering is the term used for a broad range of malicious activities accomplished through human interactions. It uses psychological manipulation to trick users into making security mistakes or giving away sensitive information. Social engineering attacks happen in one or more steps.
How Social engineering attack works?
The attack cycle gives these criminals a reliable process for deceiving you. Steps for the social engineering attack cycle are usually as follows:
Examples of this type of attack include:
How to Spot Social Engineering Attacks:
Defending against social engineering requires you to practice self-awareness. Always slow down and think before doing anything or responding.
Ways to Protect Yourself:
SOCIAL ENGINEERING ATTACKS:
Social engineering attacks can be performed from anywhere where there is even the slightest chance of human interaction. Here are a few different forms of social engineering attacks that everyone must know about.
It is one of the most prominent examples of social media engineering. In baiting, the attacker piques the curiosity or greed of the victim by using a false promise. Their attacks help lure users into a trap that hack their systems, install malware, or steal their personal information. Baiting’s most reviled form disperses malware using physical media. Baiting takes place both in the physical and virtual worlds, resulting in a loss for the victim.
Example: The attackers carry out this attack by leaving a bait, which can be in the form of malware-infected flash drives in ambiguous areas. The potential victims see these areas as it looks very authentic. Once clicked, it results in the installation of malware on the system.
In this type of social engineering attack, victims are constantly bombarded with fictitious threats and false alarms. Potential victims are deceived, and they start thinking that their system is malware-infected. This results in the installation of no real-benefit software, fraudware, or rogue scanner software.
Example: The most common way of scareware attack is legitimate-looking pop-up banners coming up in the browser while surfing the net. It may display messages like “Your computer may be affected with severe malware.” It then offers to install tools to remove this malware.
In this type of attack, the attacker gets information on a potential victim through several well-crafted lives. The perpetrator initiates a scam pretending to need sensitive information necessary to perform a vital task. The scam begins with attackers establishing a sense of trust with the victims. It can be done by impersonating police, co-workers, tax or bank officials, or people with authority. They ask a series of questions on the pretext of confirming the identity of the victim. It helps them to collect personal data, which helps them to pull off an attack.
Security Architecture and Protocols for Overlay Network Services
Conventional wisdom suggests that in order to build a secure system, security must be an integral component in the system design. However, cost considerations drive most system designers to channel their efforts on the system's performance, scalability and usability. With little or no emphasis on security, such systems are vulnerable to a wide range of attacks that can potentially compromise confidentiality, integrity and availability of sensitive data.
It is often cumbersome to redesign and implement massive systems with security as one of the primary design goals. This thesis advocates a proactive approach that cleanly retrofits security solutions into existing system architectures.
The first step in this approach is to identify security threats, vulnerabilities and potential attacks on a system or an application.
The second step is to develop security tools in the form of customizable and configurable plug-ins that address these security issues and minimally modify existing system code, while preserving its performance and scalability metrics.
This content uses overlay network applications to shepherd through and address challenges involved in supporting security in large scale distributed systems. In particular,
the focus is on two popular applications: publish/subscribe networks and VoIP networks. Our work on VoIP networks has for the first time identified and formalized caller identification attacks on VoIP networks.
We have identified two attacks: a triangulation based timing attack on the VoIP network's route set up protocol and a flow analysis attack on the VoIP network's voice session protocol.
These attacks allow an external observer (adversary) to uniquely (nearly) identify the true caller (and receiver) with high probability. Our work on the publish/subscribe networks has resulted in the development of an unified framework for handling event confidentiality, integrity, access control and DoS attacks, while incurring small overhead on the system.
We have proposed a key isomorphism paradigm to preserve the confidentiality of events on publish/subscribe networks while permitting scalable content-based matching and routing.
Our work on overlay network security has resulted in a novel information hiding technique on overlay networks. Our solution represents the first attempt to transparently hide the location of data items on an overlay network
SOS: A SECURE OVERLAY SERVICE SOLUTION
We review the SOS architecture proposed in.10 The goal of the SOS architecture is to allow communication between a confirmed source point and a target. By confirmed, we mean that the target has given prior permission to a specific user that currently resides at the source point. Typically, this means that the source must be authenticated and authorized by the SOS infrastructure before traffic is allowed to flow between itself and the target through the overlay.
Furthermore, we assume that there exist attackers in the network that are interested in preventing traffic from reaching the target. These attackers have the ability to launch DoS attacks from a variety of points around the wide area network that we call compromised locations. The number and bandwidth capabilities of these compromised locations determine the intensity with which the attacker can bombard a node with packets, effectively shutting down that node’s ability to process legitimate traffic. Without SOS, knowledge of the target’s IP address is all that is needed in order for a moderately provisioned attacker to bring down the target site. Last, we assume that the set of nodes that participate in the SOS are known to the public. In effect, no node’s identity is kept hidden. However, certain jobs that a node may perform in the delivery of traffic are kept secret from the public.
Figure gives a high-level overview of the SOS architecture that protects a target node or site so that it only receives valid transmissions. The various components of the SOS architecture (discussed in more detail later in this section) are:
Targets: Target nodes wish to receive transmissions from validated sources and wish to be protected from phony (i.e., un-authenticated) transmissions. Heavy filtering is applied in the immediate vicinity of the target to protect it from unwanted traffic. We assume that attackers do not have access to routers inside the filtered region
(i.e., they cannot observe which source addresses can proceed through the filter). Past history indicates that it is a lot more difficult for an attacker to completely take over a router or link in the middle of an ISP’s network than to attack an end-host; intuitively, this is what we would expect, given the limited set of services offered by a router (compared to, e.g., a web server or a desktop computer).
Secret Servlets: Nodes that participate on the overlay and act as the (only) entry point to a target. Their identities are kept as secret as possible.
Beacons: A beacon is a node that participates on the overlay. It receives traffic destined for a particular target and, after verifying the legitimacy of the traffic, forwards it to a secret servlet. Hence, beacons are aware of the identities of some of the secret servlets for the targets for which they act as a beacon.
Overlay Access Point (OAP): A node that participates on the overlay that accepts traffic from “approved” source points that wish to use the overlay to reach a given destination. Source points: A node on or off the overlay that wishes to send a (legitimate) transmission to a target. It is assumed that source points have been granted permission by the target during an earlier exchange (e.g., have received an appropriate certificate through e-mail).
Attack point: Any node that has been compromised and can be used to launch an attack or snoop the source from where a packet came or destination to where a packet is going (both next hop and final).
Neither the source point, target points, or attack points are assumed to be members of the overlay. An overlay routing protocol is used to deliver packets received at an overlay access point to a beacon. We now discuss the details of the design of this architecture in greater detail.
Overlay Routing
Routing used within SOS must be robust to attacks upon nodes within the overlay. In particular, if a given set of overlay nodes is attacked, there must be an efficient transition to an alternative path where no nodes are under attack. One approach is to apply the consistent hashing approach used within the Chord service.24 For our purposes, Chord can be viewed as a routing service with the following properties:
The service is implementable atop the existing IP network structure.
1.are active members of the overlay and
2.contain the information that is associated with the key. Chord also provides an efficient mechanism that routes packets toward one of those members (using O(log N) nodes in the overlay).
Control-flow integrity (CFI)
Control-flow integrity (CFI) is a general term for computer security techniques that prevent a wide variety of malware attacks from redirecting the flow of execution (the control flow) of a program.
.
As of 2016, about 86% of all vulnerabilities on Android are memory safety related. Most vulnerabilities are exploited by attackers changing the normal control flow of an application to perform arbitrary malicious activities with all the privileges of the exploited application. Control flow integrity (CFI) is a security mechanism that disallows changes to the original control flow graph of a compiled binary, making it significantly harder to perform such attacks.
In Android 8.1, we enabled LLVM's implementation of CFI in the media stack. In Android 9, we enabled CFI in more components and also the kernel. System CFI is on by default but you need to enable kernel CFI.
LLVM's CFI requires compiling with Link-Time Optimization (LTO). LTO preserves the LLVM bitcode representation of object files until link-time, which allows the compiler to better reason about what optimizations can be performed. Enabling LTO reduces the size of the final binary and improves performance, but increases compile time. In testing on Android, the combination of LTO and CFI results in negligible overhead to code size and performance; in a few cases both improved.
For more technical details about CFI and how other forward-control checks are handled, see the LLVM design documentation.
Implementing system CFI
CFI is enabled by default if you use Clang and the Android build system. Because CFI helps keep Android users safe, you should not disable it.
In fact, we strongly encourage you to enable CFI for additional components. Ideal candidates are privileged native code, or native code that processes untrusted user input. If you're using clang and the Android build system, you can enable CFI in new components by adding a few lines to your makefiles or blueprint files.
CFI detects control-flow hijacking attacks by limiting the targets of control-flow transfers. In a control-flow hijack attack an attacker redirects the control-flow of the application to locations that would not be reached in a benign execution, e.g., to injected code or to code that is reused in an alternate context.
Summary
If implemented correctly, CFI is a strong defense mechanism that restricts the freedom of an attacker. Attackers may still corrupt memory and data-only attacks are still in scope. For the forward-edge, a strong mechanism must consider language-specific semantics to restrict the set of valid targets as much as possible. Additionally, most mechanisms for the forward-edge are stateless and allow an attacker to redirect control-flow to any valid location as identified by the CFG construction. Limiting the size of the target sets constrains the attacker on the forward edge. For the backward edge, a context-sensitive approach that enforces stack integrity guarantees full protection.
Security Policies
Security policies are a formal set of rules which is issued by an organization to ensure that the user who are authorized to access company technology and information assets comply with rules and guidelines related to the security of information. It is a written document in the organization which is responsible for how to protect the organizations from threats and how to handles them when they will occur. A security policy also considered to be a "living document" which means that the document is never finished, but it is continuously updated as requirements of the technology and employee changes.
Need of Security policies-
1) It increases efficiency.
The best thing about having a policy is being able to increase the level of consistency which saves time, money and resources. The policy should inform the employees about their individual duties, and telling them what they can do and what they cannot do with the organization sensitive information.
2) It upholds discipline and accountability
When any human mistake will occur, and system security is compromised, then the security policy of the organization will back up any disciplinary action and also supporting a case in a court of law. The organization policies act as a contract which proves that an organization has taken steps to protect its intellectual property, as well as its customers and clients.
3) It can make or break a business deal
It is not necessary for companies to provide a copy of their information security policy to other vendors during a business deal that involves the transference of their sensitive information. It is true in a case of bigger businesses which ensures their own security interests are protected when dealing with smaller businesses which have less high-end security systems in place.
4) It helps to educate employees on security literacy
A well-written security policy can also be seen as an educational document which informs the readers about their importance of responsibility in protecting the organization sensitive data. It involves on choosing the right passwords, to providing guidelines for file transfers and data storage which increases employee's overall awareness of security and how it can be strengthened.
We use security policies to manage our network security. Most types of security policies are automatically created during the installation. We can also customize policies to suit our specific environment.
There are some important cybersecurity policies recommendations describe below-
This policy provides the following protection:
o It helps to detect, removes, and repairs the side effects of viruses and security risks by using signatures.
o It helps to detect the threats in the files which the users try to download by using reputation data from Download Insight.
o It helps to detect the applications that exhibit suspicious behaviour by using SONAR heuristics and reputation data.
This policy provides the following protection:
o It blocks the unauthorized users from accessing the systems and networks that connect to the Internet.
o It detects the attacks by cybercriminals.
o It removes the unwanted sources of network traffic.
This policy automatically detects and blocks the network attacks and browser attacks. It also protects applications from vulnerabilities. It checks the contents of one or more data packages and detects malware which is coming through legal ways.
This policy can be categorized into two types one is LiveUpdate Content policy, and another is LiveUpdate Setting Policy. The LiveUpdate policy contains the setting which determines when and how client computers download the content updates from LiveUpdate. We can define the computer that clients contact to check for updates and schedule when and how often clients computer check for updates.
This policy protects a system's resources from applications and manages the peripheral devices that can attach to a system. The device control policy applies to both Windows and Mac computers whereas application control policy can be applied only to Windows clients.
This policy provides the ability to exclude applications and processes from detection by the virus and spyware scans.
This policy provides the ability to define, enforce, and restore the security of client computers to keep enterprise networks and data secure. We use this policy to ensure that the client's computers who access our network are protected and compliant with companies? securities policies. This policy requires that the client system must have installed antivirus.
Essential cyber security measures
The following processes and tools are fairly easy to introduce, even for the smallest businesses. Combined, these will give you a basic level security against the most common IT risks.
Use strong passwords
Strong passwords are vital to good online security. Make your password difficult to guess by:
See how to protect against password-guessing attacks.
Create a password policy for your business to help staff follow security best practice. Look into different technology solutions to enforce your password policy, eg scheduled password reset. Find different password strategies that could boost your business security.
Control access
Make sure that individuals can only access data and services for which they are authorised. For example, you can:
Modern operating systems and network software will help you to achieve most of this, but you will need to manage the registration of users and user authentication systems - eg passwords. Read more about identity and access management controls.
Put up a firewall
Firewalls are effectively gatekeepers between your computer and the internet, and one of the major barriers to prevent the spread of cyber threats such as viruses and malware. Make sure that you set up your firewall devices properly, and check them regularly to ensure they have the latest software/firmware updates installed, or they may not be fully effective. Read more about firewalls in server security.
Use security software
You should use security software, such as anti-spyware, anti-malware and anti-virus programs, to help detect and remove malicious code if it slips into your network. Discover how to detect spam, malware and virus attacks.
Update programs and systems regularly
Updates contain vital security upgrades that help protect against known bugs and vulnerabilities. Make sure that you keep your software and devices up-to-date to avoid falling prey to criminals.
Monitor for intrusion
You can use intrusion detectors to monitor system and unusual network activity. If a detection system suspects a potential security breach, it can generate an alarm, such as an email alert, based upon the type of activity it has identified. See more on cyber security breach detection.
Raise awareness
Your employees have a responsibility to help keep your business secure. Make sure that they understand their role and any relevant policies and procedures, and provide them with regular cyber security awareness and training. Read about insider threats in cyber security.
Same-origin policy
The same-origin policy is a critical security mechanism that restricts how a document or script loaded by one origin can interact with a resource from another origin.
It helps isolate potentially malicious documents, reducing possible attack vectors. For example, it prevents a malicious website on the Internet from running JS in a browser to read data from a third-party webmail service (which the user is signed into) or a company intranet (which is protected from direct access by the attacker by not having a public IP address) and relaying that data to the attacker.
Definition of an origin
Two URLs have the same origin if the protocol, port (if specified), and host are the same for both. You may see this referenced as the "scheme/host/port tuple", or just "tuple". (A "tuple" is a set of items that together comprise a whole — a generic form for double/triple/quadruple/quintuple/etc.)
The following table gives examples of origin comparisons with the URL
http://store.company.com/dir/page.html:
Inherited origins
Scripts executed from pages with an about:blank or javascript: URL inherit the origin of the document containing that URL, since these types of URLs do not contain information about an origin server.
For example, about:blank is often used as a URL of new, empty popup windows into which the parent script writes content (e.g. via the Window.open() mechanism). If this popup also contains JavaScript, that script would inherit the same origin as the script that created it.
File origins
Modern browsers usually treat the origin of files loaded using the file:/// schema as opaque origins. What this means is that if a file includes other files from the same folder (say), they are not assumed to come from the same origin, and may trigger CORS errors.
Note that the URL specification states that the origin of files is implementation-dependent, and some browsers may treat files in the same directory or subdirectory as same-origin even though this has security implications.
data: URLs get a new, empty, security context.
How to allow cross-origin access
Use CORS to allow cross-origin access. CORS is a part of HTTP that lets servers specify any other hosts from which a browser should permit loading of content.
How to block cross-origin access
To prevent cross-origin writes, check an unguessable token in the request — known as a Cross-Site Request Forgery (CSRF) token. You must prevent cross-origin reads of pages that require this token.
To prevent cross-origin reads of a resource, ensure that it is not embeddable. It is often necessary to prevent embedding because embedding a resource always leaks some information about it.
To prevent cross-origin embeds, ensure that your resource cannot be interpreted as one of the embeddable formats listed above. Browsers may not respect the Content-Type header. For example, if you point a <script> tag at an HTML document, the browser will try to parse the HTML as JavaScript. When your resource is not an entry point to your site, you can also use a CSRF token to prevent embedding.
Why is the same-origin policy necessary?
When a browser sends an HTTP request from one origin to another, any cookies, including authentication session cookies, relevant to the other domain are also sent as part of the request. This means that the response will be generated within the user's session, and include any relevant data that is specific to the user. Without the same-origin policy, if you visited a malicious website, it would be able to read your emails from GMail, private messages from Facebook, etc.
How is the same-origin policy implemented?
The same-origin policy generally controls the access that JavaScript code has to content that is loaded cross-domain. Cross-origin loading of page resources is generally permitted. For example, the SOP allows embedding of images via the <img> tag, media via the <video> tag and JavaScript includes with the <script> tag. However, while these external resources can be loaded by the page, any JavaScript on the page won't be able to read the contents of these resources.
There are various exceptions to the same-origin policy:
Due to legacy requirements, the same-origin policy is more relaxed when dealing with cookies, so they are often accessible from all subdomains of a site even though each subdomain is technically a different origin. You can partially mitigate this risk using the HttpOnly cookie flag.
It's possible to relax same-origin policy using document.domain. This special property allows you to relax SOP for a specific domain, but only if it's part of your FQDN (fully qualified domain name). For example, you might have a domain marketing.example.com and you would like to read the contents of that domain on example.com. To do so, both domains need to set document.domain to example.com. Then SOP will allow access between the two domains despite their different origins. In the past it was possible to set document.domain to a TLD such as com, which allowed access between any domains on the same TLD, but now modern browsers prevent this.
