
cool so hi i'm lauren and today i'm going to talk about the evolution of a cyber security product how the team and i went from command line to a production ready cloud application um but first a little about myself um i joined red maple last year in may and since my first day i've been technical lead on fractal scan working designing developing thinking every day and minute about it um and that's the till i talk about today so let's start at the very beginning um our professional services team have been using a collection of open source intelligence and enumeration tools to build up a picture of a company's online estate and vulnerabilities naturally as developers wanted to
automate this and turn it turn these bespoke tools and techniques into product so fast forward one year and we have fractal scan surface an attack surface management tool that is um available for free trial right now and uses all the fun buzzwords scalable hosted in the cloud kubernetes single page app and it was built with an amazing team of six engineers so for some context fracta scan surface finds and assesses your online attack surface from a single piece of information checks for configuration issues and security vulnerabilities then summarizes this in an easy to understand score it will even tell you how to improve your score but we're not here for a sales pitch you can find us at the end
for that and we're here to go through how we did it so we'll start at the beginning and we started with an idea and worked on a prototype we were excited about the idea and the last thing we wanted to do was learn new technologies that would come later so we started with what we felt comfortable with and was quick to set up our stack consisted of javascript node mongodb and neo4j this was all in a single repo just using command line and there wasn't even a ui yet um one of the important things that we focused on um at this stage was not to be too precious with our code um it we knew it kind of get refactored it did
mostly um it was just about collaborating and testing if the idea had any legs and our code base has changed a lot in a year um but i think because we didn't have any expectations that allowed us to experiment so jump forward a month and there were a couple of us working on it full-time and we did have some interested parties uh we had proved we could gather the information and had a very basic i'd almost say ugly ui but it was exciting to think about how it could look um there was a demo on the cards and although the focus of the project was the information how we gathered it processed and analyzed it that wasn't
what a potential customer was going to see um so we needed a new ui and again we reached for something fast and simple an express server using bootstrap and view for the client in a couple of weeks we had a nice front end that highlighted the key points we wanted to get across in our demos we knew this wouldn't be the finished product but we wanted to have something we could take to people and get feedback this was our stepping stone our next hurdle was balancing running everything locally on our laptops because we wanted a working system available for our demos but we also wanted to continue to develop new features which often left our local versions in
an unstable state so having a deployed version was now critical and not only because we wanted to be able to demo regularly but also wanted to be to allow the rest of our team and company to use it so we went back to the whiteboard and redesigned the system to be scalable and deployable in a kubernetes cluster this redesign would require moving everything into separate workers adding message queues and refactoring a lot of the code that was duplicated in places and to do this mammoth change two new members joined our team at just the right time but doubling the number of people in a team doesn't always equal double the productivity we needed more structure planning and
goals we needed project management so that's what we started doing um but this was quite hard because i and we were used to being able to do anything we wanted and suddenly we had to like seek approval and get everyone aboard before starting a new idea um but our main focus em but i found it was really important to have good communication and to be able to voice our concerns because working a team can be hard but being able to communicate and adapt and makes it a bit easier so by october um we the team were working well together and we'd finished the initial refactoring um and we had 20 plus repos this wasn't the ideal number um it was a
lot to manage but we took the view that we wanted a repo to equal equal a docker container image pod so when making a change um it would be simple to just rebuild to trigger a rebuild um of one pod and not the whole system um we did find that the monolithic repo was useful for prototyping but we wanted to move to automatic deployment um and having a multiple repo pattern mean i pushed your main triggers and rebuild and deploy to repo production well in theory but we hadn't got that quite far so it wasn't all hooked up but baby steps um so we deployed fractal scan for the first time manually to arcades to our
kubernetes cluster and for the first time other people could use fractal scan it was a very exciting milestone but the work didn't stop there going from running on our local systems to a cluster had a couple of bumps one being performance we weren't sure how much resource the different parts of our system would need to perform optimally but we did know how it would perform on but we didn't know how to perform on large data sets um so it wasn't perfect first time but being able to run the system in a production environment with large data sets was very useful in identifying issues so we reassessed the system find the sticking points refactored and then be factored again
making the system better each time at the same time as this we were planning and preparing for a beta launch this is where we really had to start juggling and prioritizing requirements we wanted to add unit tests and session tests we wanted to add ci and cd continuous integration and continuous deployment we wanted to add more features but we had to fix performance issues and we had to fix bugs so in a perfect world with an infinite amount of time and attention span we would have been able to implement all of that but we didn't have the time so we implemented the bare minimum testing to make sure a change didn't majorly break it and skipped over the continuous
integration continuous deployment though the test we did implement gave us a good foundation and so that we could add more tests for each new feature and bug fix i did find at this point that it was hard deciding what needs to be done now to get our product out there and what needs to be done now to prevent a huge headache and outreaches in the future um and i think that's quite a hard thing to balance in and i'm not entirely sure if we've made the right decisions but we've got a working product in the end and at times it also felt like we're only preparing for users um to use the system and fighting bugs instead of
acting adding new features um but it was important to take this step to get feedback and confirmation that were on the right path so getting the system ready for users was important and in february 2022 we invited our beta testers to log into our system we decided to do a slow ramp up of beta testers making sure the system could cope with increased number of users we chose a range of beta testers this included ones that would give the customer point of view ones that knew what fractal scan was trying to do and our own professional services team this allowed us to get varied feedback with which elevated fractal stand and gave us plenty of ideas for future features
despite the new pressure of making fractal scan available it was great to get feedback about the product we were all excited and passionate about and the feedback was great having beta testers means that we shouldn't accidentally cause an outage whenever we release but this did happen a couple of times most definitely were not caused by me um and it was also taking us like two hours to rebuild and deploy the whole system if there was a large change which i mentioned previously we didn't want that headache so it was time to do continuous integration and it was time to have a separate production and development cluster so we switched to using helm um and like
everything else we've done in this project we did it in stages so we refactored the configuration to use helm then we moved it to helm and then we set up our build and deploy to trigger when we push domain um and then we hooked up the system test that we already had in place to rci um now it's time to add a dev cluster so um because of the changes we'd already made this was really simple all we had to do was add a new config file for the development cluster and set up m to trigger on develop so simple we actually deployed on two different clouds we were using gcp because that's where the red maple dev
cluster is and where we did our first deployment as we didn't need a separate cluster to start off with but our development and current production cluster is on ionis for a couple of reasons ionis is a european-owned company so data held in their data centers is not subject to the u.s cloud act and enables fractal scan to be gdpr compliant ionis cpus are physical cpus not virtual ones like on gcp so we get more compute power that isn't shared with others by default and it's cheaper than using the gcp servers hosted in europe it was quite nice at this point because i felt a small weight lift off my shoulders i could deploy changes to dev
and check everything still work together well and then when i was happy with it released to me i didn't feel the pressure i had to get it right the first time um and i will say that bugs still have crypto inter production system but we're not perfect and that will always happen um and it is quite a large system with a lot of moving parts so it's nice to be able to test large data sets and edge cases which are hard to replicate locally so we have a working product running in the cloud with an additional dev version available what could be next turns out there was quite a few things that we had to do
think about user management and how roles and features will work to find feature sets we had to revisit our performance again um we were originally using a dedicated graph database called neo4j but we found that the queries and the performance that we needed just wasn't there so we actually switched back to sql um and then we've just been refreshing and revising the ui for a better user experience and then working on system stability and testing but we are in the final home stretch so in the end we have fractal scan and it's exciting to think where we might be in another year um and i'll leave you with some final points that i've learned over the year
prototyping code should not be expected to be production ready prioritizing what needs to be done now versus later is a hard problem working with a good team really helps create a great product thank you for listening
are there any questions yes um so uh what fractal scan does is it monitors it tries to find your attack surface so it doesn't protect you and tells you what your issues are so you can fix it um and i'll give you a score telling you how at risk we think you are um no if you're on the internet then no
anymore
yes
so you said you were looking to deploy ci cd to for your pushes into production um how long does it take from when you do a main push to like the repos does the operational system be fully updated and ready to go um it takes about 10 minutes um if we deploy a change that affects all our repos if it's one it takes a couple minutes and then we can watch the stages go and progress and the next thing with helm is it actually checks it deploys to our kubernetes cluster properly and it's up and running um so we don't have to worry about having to go and check another system it'll fail in our ci and we'll get an
i think that's us um thank you very much [Music] [Applause]