Welcome to Siva's Blog

~-Scribbles by Sivananda Hanumanthu
My experiences and learnings on Technology, Leadership, Domains, Life and on various topics as a reference!
What you can expect here, it could be something on Java, J2EE, Databases, or altogether on a newer Programming language, Software Engineering Best Practices, Software Architecture, SOA, REST, Web Services, Micro Services, APIs, Technical Architecture, Design, Programming, Cloud, Application Security, Artificial Intelligence, Machine Learning, Big data and Analytics, Integrations, Middleware, Continuous Delivery, DevOps, Cyber Security, Application Security, QA/QE, Automations, Emerging Technologies, B2B, B2C, ERP, SCM, PLM, FinTech, IoT, RegTech or any other domain, Tips & Traps, News, Books, Life experiences, Notes, latest trends and many more...

Sunday, May 13, 2018

A few of my experiences as a Security Architect

A few of my experiences as a Security Architect

I got an opportunity to work a Security Architect role as well apart from my usual Software Architect or Leadership role in multiple organizations and wanted to mention a few of my experiences which can be beneficial for my own reference and others too who are practitioners...


  1. Embed Security as a practice in all phases of SDLC or Agile projects
    1. Security requirements tracking
    2. Security Threat modeling to achieve Secure Design & Architecture, based on the ranking we provide to risks, try to do risk mitigations and auditing in later part
    3. Make sure to have Secure Infra Design, Secure Product implementation, Secure Deployment or DevSecOps, and finally have a Secure Operations team who can monitor and report
    4. Automate the processes or steps whatever you can from the above-mentioned steps like
      1. An automated way of doing SAST (Static Application Security Testing)
      2. An automated way of doing DAST (Dynamic Application Security Testing)
      3. Apart from the above DAST, see if you can automate any other aspects of your product-specific Security testing
      4. An automated way of finding Open Source Software and Third Party libraries Vulnerability Assessment
      5. An automated way of doing Infracture Technology Hardening
      6. An automated way of doing Secure Configurations
      7. An automated way of doing Secure Deployments and leveraging DevSecOps processes
      8. An automated way of doing Monitoring and providing meaningful Security Analytics
      9. An automated way of doing Alerts and Notifications
      10. An automated way of raising Security bugs for tracking and closure of the raised earlier bugs
    5. Finally, feed some of the above and maybe not covered in above as documents or information for the purposes of Risk Management and Governance & Compliance requirements; Also, these details are really needed for Auditing purposes as well
  2. Apart from the above, have a dedicated RED Team within your organization who can manage the Security Tools chain and also perform 'defense in depth' with respect to overall Information Security and all layers in your product in a wing-to-wing manner
  3. Many times, it's a good idea to have external Penetration Testing performed by expert cybersecurity professionals before the release of the product to end customers
  4. Some of the best practices which I follow thoroughly to have a product very secure enough are
    1. Always, change the default passwords or keys of your devices or products so that those configurations are only known to you
    2. Have a Roles Based Access Control (RBAC) defined for your product and always assign the very least privilege or role possible for a given user of your product
    3. Don't trust all the machine/user to machine/user connections are trusted with respect to your product or your APIs; Have necessary OAuth or two-factor authentication implemented; Have necessary secure certificates while communicating
    4. Don't reinvent the wheel just because of Securing your products; Have a very simple reliable and resilient approach and use existing tools to achieve Security in your products. Try to see if there is already an available proven toolchain or component which can be leveraged
    5. Use generic centralized logging within your product components (like web apps, APIs, other Data, and Services) to capture the right sort of events messages which can be leveraged for Security Monitoring and then, in turn, provide meaningful insights
  5. Moreover,  implement an awareness program with the right set of documents, details, workshops, pieces of training so that the various groups in the organization are aware of Information Security and understand and practice them in their day to day product development activities


References:
  1. https://www.owasp.org/index.php/Category:Principle
  2. https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-27ra.pdf

Happy reading and learning! :)

No comments:

Post a Comment