Cyber Security Day - Memo

Post date: Jul 2, 2016 5:54:43 PM

Topics: Information Security & System Architecture, Basics of Information Security, Organizational Information Security.

Sorry, totally disorganized. Just a random memo written during the day and some thoughts.

• They claimed that it's not a good idea to put minimal working code into production. Why? Isn't that what's normally being done? That's usually also what customers want. Well, we can do this for N units, or we can do it really well and it'll cost 10*N units. Most of customers don't want the properly done version. They want the bad version. When we do the reality check most of customers are actually really happy with the cheap implementation. It does what's required for them. No, it might not be the cleanest or most secure and audited version no. But it's what gets the job done. It's easy to say this could be done better. Sure, every aspect of this code could be done better. But who's willing to pay for it? Unfortunately in most of projects all parties see security as a cost, not as essential and absolutely required feature. For most of cases it's hard to get even essential requirements, use cases, user stories and work flows gathered. If the bare essentials and integration requirements basics are really hard, it's really unimaginable to get something requiring higher level thinking included in the project.
• Same applies for access controls and physical security in many cases. Yes, we could go for the ultra paranoid NSA's going to snoop us configuration and the next cabinet is full of tempest spy hardware. But for strange reasons, customers aren't willing to pay for that either.
• Yet, it's awesome when there's a customer which appreciates these factors and everything can be done properly, instead of doing everything hastily with minimal testing and planning. If it barely works, it's done.
• Privacy by design - That's a good concept. Also not asking, storing, logging or retaining sensitive data is a good practise. You can't leak or even give to authoritative authorities information which you don't have. Sure you can warrant and raid us, but we don't have what you're asking us to provide.
• Data life cycle - So many system implementations do not actually have any way to remove data in a sensibe way. Information might be tightly locked by data relations so it can't be removed. Of course even in that case sensitive columns / data could be overwritten when there's no need to maintain that data. But guess just how many systems do it. None as far as I know. Of course the best way would be getting rid of that data completely. But the data 'clean up' code is something which is complex code and requires lot of attention. It's actually cheaper and easier just to add storage than write a proper code to get rid of data which has expired. - Even if the expiration could be technically the only right way to deal with the data. Because if there's no reason to maintain the data, it shouldn't be maintained, yet for technical reasons it still lingers in the databases and storage systems.
• Access control, access audit, credentials management, electronically signed data, traceability, logging, safe harbour, privacy shield, two-factor authentication.
• Employees neglecting security requirements and procedures. Surprised? That's the norm. We know how it should be, but we just don't care. Or it works just well even if it's totally insecure.
• Lot of talk about clarifying security requirements, especially in public sector. That's a nice dream. Often clarfiying means turning the requirements more ambiguous. 'Make a secure system' is excellent requirement, because it leaves everything open. Yet if there's a security problem we can always claim that they didn't follow the given procedure, which is to make secure systems. It's assumed that people know what making secure system means, as well as relieves the management from hard task of defining the term in detail.
• Building Information Security Culture in Business
• Security is a continuous process, it's not something which can be implemented as single shot project.
• Internet of Things (IoT) security, cloud platform security, Machine to Machine security (M2M), Internet of Everything.
• Business digitalization and related security risks like availability and data correctness.
• Data Security Certifications and Audits.
• General Data Protection Regulation (GDPR), ISO 27001, ISAE 3402 Assurance, Data Security Classification, Security Status Overview Snapshot, Access Control, Centralized Access Control / Integrated Access Management (IAM), Cyber Security Insurance.
• Daily Information Security Pitfalls. Did you leave your laptop or workstation unsecured. Have you always properly authenticated the caller / visitor? Talked about confidential stuff when not in secure environment / used insecure communication method? Used insecure terminal to check something. - That's just a few very bad examples which happen all the time.
• Information Security is Expensive.
• A few examples where extensive security audit was done. Great it was done. Was anything done to fix the issues found? No, nothing was done. Risks are now known and accepted.
• Security audits with false positives.
• Guaranteeing Security of LEAN and Agile projects with DevOps.
• How to manage situations where authority doing security assessment is asked to tell how the issue should be fixed. But that causes a problem, because if they define the way it should be done, they're not any more outsiders to the project and therefore they would be now accessing their own design. Which is ethically questionable. It's so common to be blind to own mistakes. It's much better if design and audit team doesn't work together too closely. Yet the experience of security auditor and their knowledge about generic solutions to common problems is very valuable for the developers. Just don't go too deep into implementation details.
• IoT: Smart Buildings, Smart Homes, Medical Appliances. Challenges, data availability, security, access control, integration interfaces, long term support. In world where everything older than 3 years old is 'obsolete' it might be hard for developers to grasp that smart building systems could require support for 25 before getting replaced.
• Digitalization risks: Access control, passwords, system updates, malware protection, network traffic access control and filtration, lack of backup procedures, key management.
• Fully automated security scans and attacks(!).
• Information & Data Security aspects in software development, Database security, Personally Identifying Information (PII).
• Threat modelling, context, business case, threat agents, attack, trees, misuse cases, incident response planning, security architecture specifications, security requirements, security control design, security review, architecture review, codre review, secure software architecture, security control implementation, security control testing, fuzz-testing, logic flaw testing, penetration testing, security audit, system hardening, pre-deployment risk assesment, security baseline, periodical security assesments. Phased: planning, requirements, design, coding, testing, deployment. Security categories: Design flaws, implemntation flaws, operational flaws.
• Security maturity model: Reactive, Preventative, Predictive.
• KATAKRI v3, Service-Level Agreement (SLA), Operational-Level Agreement (OLA).
• Lot more talk about: General Data Protection Regulation (GDPR) and it's requirements in business organization and subcontractors.

Pretty long post with random security related ramblings. That's all folks for now.