Foundation Certificate in Cyber Security (FCCS)
The course is part of this learning path
This course looks at the other facets of security that come into play when thinking about cyber security in general. Starting with physical and personnel security, it then moves into the secure development process, security best practice and ends with an introduction to security architecture.
The objectives of this course are to provide you with and understanding of:
- Physical security - lighting, CCTV, fencing, intrusion detection, screening, destruction, UPS and generators, access and control of entry
- People, employees, contractors, customers (resource, vulnerability, threat), recruitment, screening, Social Engineering, Common People Exploits, T&C's, in role, change in role, termination, insider threat, supply chain challenges
- Secure by Design, Secure Development Life Cycle (SDLC)
- Reduce the attack surface, defense in depth, test security, weaknesses and vulnerabilities, secure coding, learn from mistakes
- Security design architecture, enterprise design frameworks (TOGAF, ZACHMAN, SABSA), patterns (NCSC, Open Security Architecture)
This course is ideal for members of cyber security management teams, IT managers, security and systems managers, information asset owners and employees with legal compliance responsibilities. It acts as a foundation for more advanced managerial or technical qualifications.
There are no specific pre-requisites to study this course, however a basic knowledge of IT, an understanding of the general principles of information technology security, and awareness of the issues involved with security control activity would be advantageous.
We welcome all feedback and suggestions - please contact us at email@example.com if you are unsure about where to start or if would like help getting started.
Welcome to this video on security best practices.
In it, you will be reminded of some of the best practices discussed throughout this course, including:
- Running with the “Least Privilege” Doctrine;
- Creating Software that is Secure by Design;
- Testing Security plans; &
- Learning from your mistakes.
This video is supported by quizzes to help you reinforce what you have learnt.
One of the most important best practices that can be applied is that of least privilege: assigning users permissions for what they need to carry out their job. A user that has too much access or privilege is opening an attack path, whether from an external or internal threat. Running any applications with excessive privilege means that any malicious code that is attacking that application will also be running with elevated levels of privilege, giving it much greater scope for causing damage.
Software authors have a tendency to create software that works in exactly the way they want it to. However, issues can arise when the end users of the software doesn’t use it in the way that the author intended. Users will always find ways to make software behave in an unexpected fashion. How the software deals with this makes the difference between an application that is secure, and an application that is vulnerable.
Software authors should always try to write their code to handle the most outlandish user behavior they can conceive, as it is guaranteed that somewhere along the line, a user will behave in exactly that manner.
Security through Obscurity is the concept of building security into engineering as the sole method of security. Whilst security should be engineered in to a system, it shouldn’t be the only form of security. Always be a hard target for a potential adversary; do not give any attacker assistance, such as leaving credentials laying around in plain-text on your network. Whenever installing new software, mark sure that the registry keys are valid; undocumented ones can be used to gain access to your system. Attackers are persistent; they will put the effort in to discover as much as is possible about your organization, to help them in their attacks against you. Assume they know everything you know, and work from to continually improve your security.
Be prepared and test your security plans. Any security plan is only as good as the testing it undergoes. Use threat modelling to help develop and inform you security testing strategy; until you have simulated the types of pressures your security plan may undergo, you have no real understanding of how it will stand up.
Test security models within your applications – use the previously mentioned approach of believing that there is absolutely nothing that users won’t do with your software, and code accordingly; test automated scripts, delete registry files, test different levels of authorized accounts, etc.
A favorite attack strategy is to try breaking applications by bombarding them with bogus data; if your application can handle the worst that your users can do, it stands a better chance of withstanding malicious attackers.
Gain an understanding of the mindset, tools, techniques and procedures employed by attackers; understanding how an attacker might attack you will help you understand your own capabilities and vulnerabilities.
Get trained as an ethical hacker, work with pen-testers, or study incident response techniques. The more insight you can gain into the people that are looking to breach you security, the better equipped you will be to stop them.
Finally, never think that the end of a security incident means that everybody just goes back to their day jobs. Any security incident must be regarded as an opportunity to learn and improve. If you find a security problem, learn from the mistake:
- How did the security error occur?
- Has the same error been made elsewhere?
- How could it have been prevented?
- What should be changed to avoid a repetition of this kind of error?
- Do you need to update educational material or analysis/monitoring tools and processes?
The incident must be understood and analyzed to discover any potential vulnerabilities in your system. Any lessons learned from the review of the incident should be incorporated into the organizations’ procedures, or result in an update to the network’s security posture, where possible. Staff require an on-going program of education so that they can help the organization maintains a high degree of security.
That’s the end of this video.
Paul began his career in digital forensics in 2001, joining the Kent Police Computer Crime Unit. In his time with the unit, he dealt with investigations covering the full range of criminality, from fraud to murder, preparing hundreds of expert witness reports and presenting his evidence at Magistrates, Family and Crown Courts. During his time with Kent, Paul gained an MSc in Forensic Computing and CyberCrime Investigation from University College Dublin.
On leaving Kent Police, Paul worked in the private sector, carrying on his digital forensics work but also expanding into eDiscovery work. He also worked for a company that developed forensic software, carrying out Research and Development work as well as training other forensic practitioners in web-browser forensics. Prior to joining QA, Paul worked at the Bank of England as a forensic investigator. Whilst with the Bank, Paul was trained in malware analysis, ethical hacking and incident response, and earned qualifications as a Certified Malware Investigator, Certified Security Testing Associate - Ethical Hacker and GIAC Certified Incident Handler. To assist with the teams malware analysis work, Paul learnt how to program in VB.Net and created a number of utilities to assist with the de-obfuscation and decoding of malware code.