BACK TO BASICS
Architecture as a Service, or vArchitect
- We keep it simple - What is the problem we are trying to solve? And how are we going to solve it? Designs should never be full of theory. If the justifications for design decisions are important, they can be included in an appendix.
- SABSA based design without the endless theory of SABSA.
- Security capabilities covered: Threat and Vulnerability Management, SIEM, Trust (firewalls, trust boundary controls), Business Resilience Management (BRM), Identity Management, and Cryptography and Key Management (CKM).
Security Services for Small/Medium Businesses (SMBs)
- Simple, low foot-print, and cheap.
- To help SMBs requires strong foundational (IT experience + attack mindset) skills in infosec, a gift which very few in this sector possess. Large organisations can spend more than SMBs, and also can afford to not see any benefit from their investment in infosec. Poor security advice can co-exist with business almost seamlessly. SMBs however - it's a different story.
- Max of one permanent security resource is required - not a team of Big 3 consultants at £1800/day.
- A typical engagement - half day workshop to understand the environment and challenges. If is deemed useful to proceed, then a short (a few days) architecture engagement at market rates, and then there may be some engineering days, also at market rates.
- Six security capabilities are assessed, depending on the network size: Vulnerability Management, Logging, Crypto and Key Management, Business Resilience, Trust, and Identity Management.
- It is likely an economy of scales model could be proposed based on usage of a trustworthy and highly skilled Managed Service Provider.
Cloud Migration - Engineering and Architecture
- Architecture - see above.
- Engineering - TVM, SIEM, IDAM.
- Platforms: AWS, Google Cloud Platform, Azure.
- Integration of security capabilities with existing devops processes and technologies.
- See profile
- Vulnerability Assessment - VA++.
- SAST support - initation of fix integration in to CI/CD.
- DAST - "Blind" OWASP testing.
- Splunk, Alienvault, open source architectures with Rsyslog.
- Splunk "clean-up" - assistance with excessive logging scenarios.
- We only work with clients who are interested in development of use cases for the purpose of alerting - i.e. seeing some benefit for their investment.
- Strategic and tactical Development of Security Operations functions, and incident response.
Threat and Vulnerability Management
- Infrastructure Penetration Testing.
- Application Security - "blind" OWASP testing.
- Designing capabilities for TVM - people, process, and technology - how does the organisation respond to an identified vulnerability?
Oracle Database Security Health Check
- 10g, 11g, 12c.
- Automated scanning using Musang.
- Follow up on vulnerability assessment with remediation advice.
- Splunk apps.
- Python, Django, BASH, Ruby.
- Types of engagement:
- Bridging gaps between product functionality and required functionality.
- Development of scripts for automation.
- Debugging existing automation.
Ian Tibble graduated from City University (London) in 1991 with a BEng in Computer Systems Engineering, and then went overseas in Oil & Gas exploration ("Seismic") in Algeria, Turkey, Yemen (twice), and UAE, with an accidental crossing into Libya in the deep south of the Sahara.
Ian then used his degree to get into IT at the age of 25, with first Sun Microsystems, then IBM Global Services.
In 1998 Ian joined Trusecure's testing and research lab in Asia Pacific (now Verizon Business), serving clients in banking and telcos, in Thailand, Malaysia, Indonesia, Hong Kong, Taiwan, and Australia. These first 5 years in red team/unrestricted penetration testing laid the foundation for Ian's career and gave him an attack mindset, to be followed by 2 years in DHL's ITSC in Prague, where "the other side of the fence" (defence) was the priority.
After a spell with PwC, the next 8 years up to 2015 saw Ian engaged in multiple sectors: Insurance, Telecommunications, Legal, Banking, and Trading (London Stock Exchange Group).
More recently (since 2015) Ian has been engaged as a architectural/engineering resource on cloud migration and devops projects for HSBC and HM Government (multiple departments).
Latest Blog Post
Fintechs and Security - Part 4
April 12, 2020, 7:15 p.m.
Notice "Logging" is used here, not "SIEM". With use of "SIEM", there is often a mental leap, or stumble, towards a commercial solution. But there doesn't necessarily need to be a commercial solution. This post invites the reader to take a step back from the precipice of engaging with vendors, and check first if that journey is one you want to make.
Unfortunately, in 2020, it is still the case that many fintechs are doing one of two things:
The process HLD takes into risks from threat modelling (and maybe other sources), and another input from compliance requirements (maybe security standards and legal requirements), and uses the requirements from the HLD to drive the LLD. The LLD will call out the use cases and volume requirements that satisfy the HLD requirements - but importantly, it does not cover the technological solution. That comes later.
Security De-engineering, published by Taylor Francis, covers ubiquitous problems in information security and offers a solution in the final chapter
Areas covered: Penetration testing, Hackers, CASEs (Checklists and Standards Evangelists), IDS, Cloud Security, jobs in security, Identity Management, and organisational elements.