Understanding security operation

1. Understanding
Security Operation

2. 1. Creating collaboration across teams to
account for security in the application
and software development lifecycle.
2. Increase visibility of the security
infrastructure for stronger security
practices.
3. Ensure that management has bought
in at all levels to create a roadmap to
increase and improve the
organization’s security.
Goals to Security Operations

3. Components of Security Operations
• Earlier detection and prioritization: SecOps tends to focus on checking smaller, more
productive segments rather than large batches or entire programs at once.
• Increased transparency: The increased ties and collaboration between development, security,
and operations can create transparency.
• Security improvements: SecOps improves security alongside the programming and operational
aspects of DevOps.
• Threat awareness: SecOps teams are typically trained in security operations to ensure that
everyone understands the security threats.

4. There are two types of operational security problems:
1. Accidental misconfigurations: These are accidental in nature, and are by far the most frequent
type of operational issues. Mistyping a value (such as the route target in MPLS VPNs) is one
example, or forgetting statements in a firewall is another example.
2. Deliberate misconfigurations: These are deliberate in nature but vary in their degree of
maliciousness. For example, violation of the security policy to allow an operator's home system
access through the corporate firewall is not as likely to be as severe as acts of sabotage by a
disgruntled employee.
Operational Threats

5. What does Security Operation Centre do?
● Continuous network monitoring: Careful monitoring of a network includes everything in
the IT environment, including public, private, and cloud infrastructures.
● Incident response: Any sign of unexpected activity on a network can be indicative of a
security event. It is the role of the SecOps team to implement incident response
protocols and take the appropriate steps to contain any damage or take preventative
measures.
● Forensics and root cause analysis: Post-incident analysis is a crucial responsibility of the
SecOps teams. This is the opportunity to assess and analyze security incidents and other
unexpected events to find the root cause, whether there was a breach and loss of data
or if there was just a software performance issue.
● Threat intelligence: The process of gaining knowledge about possible security threats,
and planning methods to prevent or respond to events.

6. 1. Security threats grow and become more and more creative every day. It almost seems like there
won’t ever be enough people in an IT security program to dodge every attack and prevent every
security incident from occurring. A more robust team can help with the deployment of
applications and help oversee the security during all phases of deployment in order to grow a
team and put more hands on deck.
2. Speed and tool adoption are prioritized over security. Often, operations and development
teams are concerned with the speed of applications and their usefulness as a tool. When there
isn’t enough emphasis on security, an application can be vulnerable to attacks and become
compromised.
3. Innovation has outpaced security and it is crucial to keep security side by side with innovation.
Otherwise, an innovation can just be a liability and a vulnerability.
4. Time to exploit vulnerability has decreased as cybercriminals are becoming more and more
creative with their attack methodologies. Faster security responses are crucial to protecting
data and the integrity of a company’s information.
Why Operational Security needed?

7. The typical reaction when looking for a solution to a security problem is to look for features to
configure. It is important to understand that operational problems cannot be fully solved by
features, because the person making the misconfiguration may also remove the feature that is
meant to protect against misconfigurations. Operational problems require operational solutions,
and operational competence of the organization.
Few points must be included in Operational Solutions:
Operational Security Measures

8. 1. Operational Security Policy:
There should be clear guidelines on what operators
are allowed to do and what they are not allowed to
do. Escalation paths need to be defined that outline
the steps to follow if an operator does not have the
authorization required for a specific action. The
operational security policy should clearly define the
responsibilities and authorization, as well as
disciplinary actions in case of breaches. The policy
also acts as a deterrent against deliberate
misconfigurations.

9. 2. Change Management Process:
Every company running a network should create
precise processes that define and control how
changes to the network are executed. The state of
the hardware, operating system, and configurations
should be monitored, and all changes should be
logged and executed in a controlled way. The logs
should be evaluated and checked for potential
misconfigurations. The logs can also be used to
demonstrate a deliberate breach of the operational
security policy.

10. 3. Access Control:
It is a good practice to restrict access to network
devices. Access restrictions are traditionally
implemented in networks via any authentication.
This security measure is typically executed,
although in many networks too many operators
have access to network devices. Restricting this
number to the minimum amount of operators
necessary reduces the risk.

11. 4. Authorization:
The access an operator has should be restricted to
the minimum access needed for the operator to do
their job. In most cases it is not a good idea for all
operators to have full-enable access to devices. This
practice can be more difficult to implement;
however, simple distinctions, for example, who can
and cannot enter configuration mode, go a long
way.

12. 5. Dual Control:
Security control and network control should not be
the responsibility of the same group. Ideally, a
security group controls who has access to what,
and a network group executes the configuration
actions. Typically the logs are controlled by the
security group. This way it is much harder to
deliberately misconfigured devices, since the
security team could recognize a misconfiguration in
the log files.

13. 6. Secure And Verify:
All of the above measures are active attempts to
detect a change in the network, such as a
configuration change. It is also possible to detect
policy violations by analyzing the traffic on the
network, or the state of dynamic information such
as routing tables, ARP tables, etc. For example,
intrusion detection systems can create alerts when
flows are seen on the network that do not
correspond to the policy. There are many other
ways to monitor for traffic anomalies. For example,
Cisco NetFlow can be instrumental in detecting
misrouted packets on the network and routing
tables can be checked for missing or unknown
routing prefixes.

14. 7. Automation:
It is generally recommended to automate processes
and procedures, specifically recurring verification
processes, because humans tend to overlook
details in log files and similar processes. Automated
processes are also less likely to make mistakes,
although if a mistake does happen, it is often
systematic and therefore easily detectable.

15. Here are underlying principles for building secure systems.
• Accountability: Hold principals responsible for their actions.
• Defense in Depth: Prefer a set of complementary mechanisms over a single mechanism.
• Non-Secrecy of Design: Security shouldn't depend upon the secrecy of design (or mechanism).
• Economy of Mechanism: Prefer mechanisms that are simpler and smaller.
• Failsafe Defaults: Presence of privilege, rather than absence of prohibition, should be basis for
allowing operation.
• Least Privilege: A principal should have the minimum privileges it needs to accomplish its
desired operations.
• Complete Meditation: Every operation requested by a principal must be intercepted and
determined to be acceptable according to the security policy.
• Separation of Privilege: Different operations should require different privileges. Single
operations might require multiple privileges.
Principles of Security

16. This is a principle behind real-world security, and it holds for software security, too. Consider a bank
vault. It has a lock, key(s), and a video camera:
• The lock prevents most principals from taking any action.
• The key enables certain principals to take actions.
• The camera holds any principals responsible for visible actions.
In the real world, we don't make perfect locks or keys or cameras. Instead, we do risk management.
We buy insurance. (It's cheaper than building perfect locks, etc.)
Mechanisms for accountability are separated into three classes:
• Authorization: mechanisms that govern whether actions are permitted. e.g., file permissions,
firewalls, visibility restrictions in FB
• Authentication: mechanisms that bind principals to actions. e.g., passwords, digital signatures,
EV certificates in browsers
• Audit: mechanisms that record and review actions and the principals who take them. e.g., log
files, log browsers, intrusion detection systems
1. Accountability:

17. Complementary means
• independent, such that attacks can't penetrate all at the same time, and
• overlapping, such that attackers must penetrate all.
For example, your bank might use both a password and a hardware token to authenticate
customers. Your apartment building might have multiple door locks and a security system. And your
university IT department might use firewalls and virus scanners to prevent spread of malware.
2. Defense in Depth:

18. Assume the enemy knows the system. For example, assume the enemy knows the encryption
algorithm, but not the key. Or, assume the enemy knows the model of a lock, but not the cuts made
in the key. We saw this principle appear in cryptography, where it's called "Kerckhoffs's Principle."
Non-secrecy is frequently violated by beginner. Note that there's nothing wrong with keeping a
design secret if security can be established by other means. That's just defense in depth.
The principle of open design asserts that complexity does not add security…it just makes things
more complex.
Security through obscurity is not security!
3. Non-Secrecy of Design:

19. They're easier to understand and easier to get right. It's easier to construct evidence of
trustworthiness for small, simple things.
In any system, there's some set of mechanisms that implement the core, critical security
functionality hence must be trusted. That set is called the trusted computing base (TCB). Economy of
Mechanism says keep the TCB small.
4. Economy of Mechanism:
5. Failsafe Defaults:
It's safer to forget to grant privilege (in which case a principal complains) than to accidentally grant
privileges (in which case principal has an opportunity to exploit them). For example,
• default access to your files should be that only you get to read and write them; and
• default privilege for your web browser should be that it isn't allowed to read or write your disk.

20. Experienced system administrators know not to login as root for routine operations. Otherwise, they
might accidentally misuse their root privileges and wreak havoc.
Likewise, a web browser doesn't need full access to all files on the local filesystem. And a web
front-end doesn't need full write access to a database back-end for most of its operation.
6. Least Privilege:
7. Complete Meditation:
The component that does the mediation is called a reference monitor. Reference monitors should be
tamper proof and transparently correct.
Each time the subject tries to interact with an object it should be checked again and not cached.

21. Financial institutions frequently employ this principle. Two tellers might be required in order to
open a vault or disperse a large amount of cash.
Separation of privilege restricts access to system entities. A system should not grant permission
based on a single condition.
Example: in IT when someone wants to request elevated permissions they must be administered by
a separate entity and possible also a document that describes the work to be done.
8. Separation of Privilege:

22. ❖ Security depends on architecture, implementation and its operations.
❖ There can be accidental misconfigurations and deliberate misconfigurations.
❖ Implementation of Security Operation Centre is important for a big organization.
❖ There are some security principle that we should keep in mind when we implement security
operations.
Summery

23. Thank
You