Building Secure Architecture Patterns

0:00Today's agenda is all about we will learn about a brief introduction about security architecture or architecture in general. What exactly is an architecture where exactly security architecture fits in nothing in detail but at a high level so that probably we can have a uniformity around the audiences like everybody understands what we are talking why we are talking and all this kind of stuff. And then we'll talk about what are architecture patterns, what does a good pattern look like, what are the things you need to include, what are the things you need to exclude everything. How do we enforce the security architecture patterns? This is very very interesting. We will talk about building a pattern is fine, right? But the enforcement of pattern is very crucial at an enterprise level. So how do we do that? And then we will build a pattern together. As I promised, I have a pattern that I've created just for this particular cohort this this this evening and we will see how exactly it looks like.

1:01So let's talk about what happens when you try and build any kind of a system solution service you want to incorporate a new capability in your organization, but you don't have an architect. Why architecture is important? Let me show you something. I hope everybody is able to see some of the pictures on the right side of your screen. This is a design of a house, right? You can probably see these are the stairs and then it actually follows up the stairs here and there's a door, right? And you probably would be able to see here these are the steps and we have a steps here and there's a toilet seat. I don't know how someone would be able to manage it here. You know why exactly these things happened because there was no architect involved in terms of designing the house. You all would have probably got your house built or maybe you have an aspiration to build a house for yourself.

2:06When you want to build a house for yourself, do you straightaway go in and hire some of the construction workers and tell them that, hey, I need a house. And do they start building a house for you? No, not at all. Why? Because the workers, the construction workers need to know what kind of a house you need. Do you need a house which has a kitchen, which has a bedroom, which has a living room, which has a study room, which has washrooms? And you're going to be like, yeah, isn't that obvious? Now, nothing is obvious. You as an owner of the house, you need to clearly tell your construction workers what kind of a house you need. Let's say you go ahead and say, well, I need three bedrooms, one living room, one dining room, which is kind of a living room and dining room accommodate, one kitchen, and maybe two or three washrooms.

3:06And maybe we can have a couple of balconies. That's all, right? Brilliant. Do they still have enough information for them to start building the house? No, because there's no layout, no plans, no dimensions, how big your room would be, how big your kitchen would be. Otherwise, what would happen? Someone's house is going to end up looking like this. If we don't have a proper design, that is the reason design matters a lot. Without a proper design, nobody knows what we need to be, what we need to build, right? That is the reason whenever the end, you don't end up building your house every single day. Do you? You don't? Everybody get their house built once in their life. Most of us, right? I can't talk about everyone else, but most of us have an aspiration, have an ambition to build a house once in a lifetime.

4:11So you do not want to have any mistakes, you do not want to have any sort of challenges around it that you ask someone to build a house for you and you don't like it. Because that is the place you're most of the time you're going to spend right to third of your life, you're going to spend any side of your house, right? That is the reason the design matters. Otherwise, what would happen? We all are going to end up something about a situation like these. That is the reason you need to have a good architect, a good architect, not only for constructing your house, a good architect, someone who is going to help in building your solutions. Either building a solution or buying a solution, you are trying to reuse any capabilities. It doesn't matter. Architecture is one of the most important elements that every enterprise needed, right? Without an architect, an organization is going to end up having a solution that just looks like this. People are going to end up complaining, people are going to either get it, they would end up getting overwhelmed that they don't have anything what they look out for and they end up having either excessive features, capabilities that they never wanted or maybe they don't have anything.

5:32That is the reason an architect is very important. What why exactly architecture is important? Because it allows you to succeed. It helps you in getting where you want to be, right? Or it allows you to fail fast. The job of an architect is to make sure that you be there where you want to be or you immediately figure it out what are the challenges, roadblocks that we are facing and how we can improvise. That is exactly what agile transformation is all about, right? Either you succeed or you fail fast, right? In architecture, there is a term what we call it as, as is and as to be. What it means, as is, is what exactly or where exactly you are? It is the thing of it like your current state of your particular structure, right? And as to be, is where you want to be? Think of it like as a target state.

6:36So you would have a current state, you would have a current based off your current scenario, current set of application solution, capabilities and you want to be here. You have a vision, you want to be there, you want to succeed, you need an architect to help you be there, right? As an organization, you might not have let's say an ERP solution, enterprises, resource planning, right? ERP solutions are used in almost every organization or maybe an HR solution or maybe a CMDB or maybe you need an IAM solution or SIE or DLP, whatever the solution might be, right? Currently, you might not have it, but as a part of a requirement, as a part of the business requirement, you might need that, right? So that is where the architect, what they do is they understand the business requirement based on the business requirement, they help in building the designs, based on those architecture decisions, they help in incorporating or enabling the technologies,

7:44based on those technologies, you understand how exactly you will implement and how exactly you will operate. These layered approach helps an organization to achieve where they want to be, whatever they have envisioned, they want to be there, right? And who's going to help them in being there, your architecture community, they are the one who are going to help you in being there, right? An architecture is very important because it reduces the complexity. A complex design is very poor design. We all might have learned about one thing in security, I am assuming all of us have some of the bits of experiences in security, right? So there's one common statement that we all have learned that anything that has a complexity that is difficult to protect. Easier, the elements, easy to protect, right? In architecture, what we call, we have a principle called as, keep it simple, silly.

8:50What does it mean? Similar, the design, easier it is to protect, right? So an architecture helps you in reducing the complexity. There's a very important enterprise architecture principle that we have. That principle states, whenever you need a new solution, think or see or explore the opportunities, what if you already have that solution in your enterprise, which means they emphasize on reusing the particular capability existing capability. I need an ERP, I need a CMDB, I need an HRMS, I need some kind of a issue tracking defect tracking, something like that. Do we have something that exists in my organization? Can that help mean solving that problem? If yes, I don't need to think about anything else, that particular technology capability I can actually reuse. If not reuse, the objective is we can either build or buy the solution, right? Buying the solution always takes precedence. Why there's several benefits, buying the solution reduces the time, time of the implementation cost.

10:00It's a little bit expensive in the beginning, but in the long run, buying the solution is easier, because when you build the solution, you have an internal staff, but then you have to keep those internal staff just for maintenance, production release, production support, plenty of the things, right? Buying the solution in the longer run becomes quite reasonable, it's a better decision. If you can't buy it, then only think about building it. So when you have an architecture community or architecture as a function in your organization, it helps in reducing the complexity, saving the cost, time and satisfying the customer need. I'm going back to that particular analogy of you building a house. When you don't have an architect, simply imagine you gave a requirement that you need a house, free bedroom hall kitchen and everything, without any architectural description, blueprints, layout dimensions, you would never be satisfied if your house turns out like this. Similarly, the business won't be satisfied in case if there are application terms or something similar to this, right? That is the reason architecture is very important.

11:09It ensures the uniformity and consistency across enterprise. That's what what an architect does. Architecture have their own principles, their own design principles, their patterns and everything, where any solution that is either being developed, bought or being reused, it must be in accordance to the organization's principles there. For example, I'm just going to give you a random example that let's say an enterprise have the configurations of they must use the database is like sequel and Oracle only as a random example. There's nothing wrong with any other databases, but let's say an organization only advocates that if they if anybody is going to use a database, that must be either sequel, that must be either Oracle. If someone is using a particular operating system, that must be either Windows or Linux, right? We don't recommend using debut and Ubuntu or anything else.

12:09Anything wrong with those OASs? Oh, no, nothing wrong. It's just that has not been vetted from an enterprise architecture perspective. So what happens? Every application that exists in the particular organization that people have built. They all have either sequel or Oracle as a database. They all have Windows or Linux as a platform. They all have specific app, let's say programming language where it was used to build, right? For example, you only advocate, let's say Python Java, C++, dark native, so on. You're not recommending people to use, let's say, your full stack developing. I'm just randomly giving an example. So what happens? Anyone using a solution, they are building a solution that deviates from the given principles that automatically becomes a technical debt, right? A technical debt means anything that doesn't follow an architecture principles, right?

13:15So an architecture ensures that the entire capability components, whatever the things that you're building, they all are uniform and consistent across enterprise. And the additional benefit you get, it provides that degree of confidence among the customers, your stakeholders, that particular solution was built according to the design principles, according to the engineering principles. And this has gone through various sort of assurance and governance requirement, right? That not only builds the quality system and software that also ensures the security element were incorporated, it's resilient by design, right? Today nowadays, enterprises have a huge drive and push towards incorporating or enabling resilience by design. That means they want to enable the capabilities where they simply in case of something fails, any component is not up and running, they can immediately switch and move to something that provides a similar capability without having a trouble of rebuilding anything from scratch.

14:25That kind of a assurance that they're looking for. That is exactly why architecture is important. What happens when you hire a good architect, when you hire a good architect, you get something like this, your dream house isn't it, right? You not only have a wonderful architecture outside, you have wonderful entrance, your courtyard, your garden, you have some of the parking lots, a nice lovely car out there. But you also have a lovely interior, look at the living room, you this is exactly what a dream home would look like. Of course, it's subjective to people's preference, but there's nothing wrong with this entire living room. Why? Because this is what happens when you hire a good architect and not only for the construction business or not only for the home requirement, this goes at very macro level when you want to have a new solution,

15:25when you want to buy a new solution, when you want to build anything, that's exactly why an architect would be needed. Right? So I always reiterate the same thing again and again, where do you need architecture? Your architecture would be needed right from the beginning. So if I quickly write down one of the high levels SDLC phases, so you have your requirement gathering, design, you have your development, you have your quality assurance or testing, or you have your ops and maintenance. Right? Where exactly you see your architect doing their job, it would be at your design phase. Right? Because in case if you introduce architecture at the later phase, let's say, hey, I have deployment tomorrow, can you see if my design looks okay?

16:25Does it really matter if the design looks okay or not? Okay, because it's impossible to go back and change anything because you have a release next week, isn't it? Right? That's where what happens, and I think I can speak for everyone. Whenever we, no matter whatever the organization we work for, you always find a culture in your organization that people think about introducing architects at a very late phase, realizing that they are just here to give us like a sign off or an approval before before we go ahead and either purchase a solution or the decision has already been made. We just need some kind of a, it's no longer check box exercise. Right? That's exactly why you need an architect as as early as possible. What about security architects? What exactly a security architect does a security architect is someone who review the designs based on in the, based on the security standards policies, whether it is in accordance to the given requirement.

17:33And it also suffices and fulfills the regulatory requirements, everything around it. That's what a security, security, security architect would do. You've got your house built. You still need your fences, you still need your doors, locks, your CCTV cameras, right? Otherwise, what would happen? You have a lovely nice house, but it is wonderful. If you don't design your house securely, building the house, building a lovely house won't make it long lasting because, you know, right? That people are there. We don't live in a community. We don't live in a society where an ideal house without any security elements would be able to sustain at a very long time. So it's very important that we need to build security capabilities around us. Otherwise, what would happen are solutions in case if they have not incorporated security right at the design phase, it would not be secure.

18:40It would not be sustained for a very long time. The idea is not to retrofit security based on whatever has already been built because you cannot put, you cannot crown the security on top of the solution. You can't, you need to, there is a very popular saying in security that you security must be baked in rather than bolted on. What does it mean? It simply means security must be incorporated in the initial phase in the design phase as quickly as possible so that we know whatever we have built, it has the security element. And it must be integrated throughout the development phase everywhere, right? All right, let's talk about what are architecture patterns? What is a pattern? A pattern is anything that is a reusable requirement for common recurring problems.

19:46A pattern is built based on any kind of problem that you have identified and that problem should not be unique. It should not be an isolated problem. For example, you have a requirement of sending a file outside. Let's assume that, okay? You have a requirement of sending a file outside to your external customers, partners, suppliers, or maybe you have a requirement of receiving the file from them, right? Is this one of a requirement or is it going to be a recurrent requirement? Let's say it's one of the requirement. You probably discuss how large the file would be. What kind of requirement is it? It's like they say like probably 10 MB, 15 MB, one of the requirement. Maybe we can actually use email, right? But what if tomorrow the business says, well, we need to receive the file every single day and there's not only one business.

20:46Every business says, well, we have a requirement of receiving the file. We have a requirement of sending the file. That means it has started becoming a recurring problem statement. So rather than evaluating the requirement one by one unique cases by cases, business requirement by requirements, what we do, we build a pattern. What exactly is a pattern? Parton is finding a solution that could be repeatable. That is something reusable. Something that could fix our problem for every recurring instances. Right? We don't have to go back in circle again. So let's say whatever the file transfer requirement would be, any business wants to transfer a file? Well, we have a pattern. Go ahead and start using that. Why pattern is important? Building an architecture pattern helps in all the delivering all the velocity momentum.

21:49If anybody identifies a problem statement, if that has already been discussed, addressed, approved, we know there's a pattern we can simply use it. Right? So as an architect, as a solution architect, as a security architect, whatever your job responsibility is, right? Whenever you review any kind of a solution, whenever you review any kind of design, you simply ask, what is the problem statement? What are you trying to solve? And is it following the approved patterns? If it is following the approved patterns, you don't have to worry about it because you already identified established reviewed. You'd vetted that particular pattern and that is something if it is being used, you don't have to worry about it. Right? So it actually helps in enabling foster design decision. You can swiftly immediately take that decision. It helps in reducing that security gap because if I know that we have identified a particular pattern for secure file transfer or maybe employ authentication or maybe secure data security.

22:58Or proper session management logging monitoring, whatever it is, right? We know if someone is following that particular pattern, that is okay for us to move ahead, prove and it actually enables the easier onboarding of any kind of a solution application. Either you're buying something or building something doesn't matter. We know if it is meeting our requirement. It is, it is where we are happy to review and endorse that particular design. Right? That's why architecture patterns are important. Right? Patterns think of it like I took the liberty of using this particular image because there is an important description behind these Lego blocks. I hope everybody would have played with Legos, right? Everybody understand what's the Lego? Legos are the simple blocks that you have when you build any kind of a structure or architecture, whatever the things that you have. Right? Now with those Lego pieces, you can build anything, isn't it? Right? You can build anything whatever you want. But you you you get when you want to have a Lego, whenever you buy a Lego, it comes with an instruction booklet.

24:11Everybody would have in case if you played with Lego, maybe if you have kids at home, if they have played with Lego, it comes with an instruction booklet. Think of that instruction booklet as a pattern. It helps you in building the exact design, what you expect, what it what you want to build. Rather than getting confused, how do I use this? Where do I use this? How do I incorporate that in my particular building blocks? That's why we need architecture pattern. So what exactly is a pattern? Pattern is not some kind of a rigid template, some kind of a specific use case that you have. It's something that provides the uniformity consistency across every solution that we want to have. So a pattern is a reusable solution to a common recurring problem. Right? In case if someone wants to have, let's say you have a specific file transfer pattern or maybe employee authentication pattern, you don't have to review them again and again.

25:15If you have an application that delivered that transmits the file integrates with external systems, perform employee authentication. If you have the designated patterns, you can simply go ahead and review it and approve it. You don't ask them, how do you authenticate? Do you support SSO? Now, because that particular solution, if they already follows your authentication pattern, you don't have to ask any further question. Simple, swift, easy to easily read comments. Right? That's what the architecture patterns are. Right? Now, what exactly a good pattern looks like? A pattern is not merely a design or a diagram. A lot of people often often have that misconception that a pattern is something just a diagram or a design something that we need to think about building the design if I'm going to make it and it should be that that's where our job is done.

26:23No, a pattern must have a defined problem statement. What are we trying to solve here? And why? In architecture, not even a single step we take until and unless we have a proper business use case. An architect is someone who works closely with the business. An architect is someone who understand the business context. If you don't understand a business context, you won't be able to deliver what exactly is needed for the vision and mission of the organization. Right? You can spend decades in technology and security and you can be really, really good at one, two, three, ten different things. No doubt about it. Right? You can simply excel all the things. You can be a good application security professional. You can do perform pen testing. You can perform threat hunting intelligence.

27:25You can simply set up weeping connection site to site weeping whatever you want to do it. Right? But if you don't understand the business domain. As why this is needed for the success of the organization. You won't be able to deliver the architecture piece of it. All right, as we're going to progress, I'm going to share some of the real world examples around it. Why exactly I'm emphasizing so much on the business requirement. One cannot be a good architect. Right? Yeah, of course anyone can simply get into a role of an architect and they can call themselves architect, but one cannot be a good architect if they don't understand their own business. So if you're working in a health care, you need to understand what exactly health care does. How exactly your organization earns money? What are the various regulatory requirements that you have to address? If you work in a bank, you need to understand how bank earns money. What are the way you don't need to understand the technology stack. You don't need to know what are the various things. You just need to understand.

28:33You have a 10,000, 20,000 feet view of how the operating model or a business model of a particular organization looks like. If you're working in a manufacturing company, think about how the organization makes money. If you're an investment company, think about how the company makes money. These things are very, very crucial for anyone to become an architect. And I'm telling you because this is exactly what an organization looks for if you want to apply for a role of an architect, see an architects enterprise architect, principal architect. These are the very, very important things that we, anybody would look out for. All right. So what exactly a good pattern look like a pattern must have a defined problem statement. If there is no problem statement, you don't need a part. If there is a specific problem statement that is one of our odd cases, you don't need a pattern. Think about solving that problem with one of the existing patterns, existing capabilities, existing solutions out there.

29:34Not everything deserves a pattern. Just because someone need a specific requirement, you don't need to start building a pattern. First of all, identify the problem statement. For example, need of a send, need of sending files, security to external entities or consuming files from external entity, integrating external services, employee authentication customer authentication, or maybe collaboration between your, your company and other companies. I take architecture classes as well. One of the case studies we discuss is how do we build collaboration between your company and let's say your customers or partners company? How exactly those sessions, those integrations would be needed. These are the problem statements that you need to identify. Right. Once you have identified the problem statement, you need to understand when you can use this pattern. For example, I'm going to take a reference of need of a file transfer. Right. When do you want to use it? Inbound, ingress connection, egress connection, what kind of data you would be and it would be involved. Why exactly it is needed? When are the instances you would need it?

30:45Your pattern must describe this. Right. Your pattern must describe this. It must have the components. Right. What are the components you would need? Actors, actors means users like consumers, senders, receivers, your employees, your customers, partners, suppliers, vendors, anyone. These are the actors, right. External actors, internal actors. In architecture, we even have the color templates. Like for example, any internal users or actors we define in green. That's a very common color combination. Right. Any external actors we define when they're red. Right. Nowadays, it's very neutral color. So probably we can use something like a blue and a grace. And it's up to you. How you want to depict it? Right. It's a great client's gateway authentication and all this kind of thing. These are the various components that we need to have it. Should contain security controls. In case if you want to build any kind of a pattern that might require a security element, that should contain security control. For example, how do you plan to authenticate? How do you plan to authorize? How do you plan to encrypt? In case if you want to have some kind of isolation of the network segment.

32:02All those things need to be clearly depicted in the pattern. What are the tradeoffs? Whenever you want to build a pattern, whenever you want to build any capability, there is always some form of trade off. Always. No pattern exists without any tradeoffs as simple as that. Because if you want to suggest any kind of a pattern, you might have some kind of a trade of like more complexity. Right. For example. In the cases of file transfers, you are not integrating external entities to internal entities directly. Right. For example, they cannot go ahead and access the file from this particular system. They need to have a file from this particular location. They cannot simply go ahead and access it. That's that might look simple, right. But that's not secure. So what we plan to do is we plan to take this particular file, drop it into a some kind of let's say in DMZ in some of the location. Right.

33:07That particular external system can pick it from here or maybe in case if they have to drop a file, they can drop it here and we will pick it from here. Right. No direct interaction. It's a slightly complex, but it serves the purpose. Right. And you might want to encase any of the files that are being dropped here. They you might want to scan for the presence of malware, data validation, all those kind of thing. That food. Degree the performance any security control that you implement that is always going to have a compromise on performance always. And it's not only for malware scanning. It is for anything. DLP scan DLP controls VPN MFA you name any security control. There's always going to be some form of performance. Operational overhead. Now you need to have the management of this particular staging server, whatever it is. It could be a file transfer server. It could be anything. You now have to take care of that particular server as well. That's an operational overhead.

34:09But these things are very important that you clearly depict. Not very widely included in the patents, but nice to have if in case if you also want to have add another section of it. I mean, I haven't I didn't do it deliberately because they don't generally go really in the patents, but you can also think about add another section of the how part. How part means how are you planning to implement it the implementation. You might need specific technology for that. For example, in case if you have an FTS file transfer service, you can have an AWS FTS service or maybe you can have some kind of a IBM file transfer services. You can have some kind of a messaging queue. Whatever it is needed right the technology aspect on how you can go ahead and start implementing these patents. So these things are quite useful, important while you're building a pattern for yourself.

35:13Identify the use case and start developing the patents around it. Something that can be repeatable, reusable to deliver this particular solution. Now the pattern is developed, but how do we enforce that how does the enforcement look like? Well, for the enforcement, we have various review forums. In an organization, you have pattern review boards. For example, in case you have developed a new pattern, you go and get it through the get it reviewed through pattern review board. Generally, the enterprise architect domain architects and of course there is a domain architects means there is a particular architect for specific domain. For example, security enterprise security architects represent this entire security community data architect would be there network architect would be there everyone sits in that particular forum. When you get and develop a new pattern, they would address your concerns why exactly you created this.

36:14What was the problem that the company or an enterprise had it? What was the use case or needed for this? So once you have developed a pattern, you need to explain the viability of it, the explain the usability, ease of implementation feasibility, everything need to be explained. And then they simply say, okay, yeah, it's it's good. It's definitely going to solve a problem at a large scale and you can actually deliver this. Then once the pattern has been approved, that goes into the enterprise pattern library. You can call it as a repository. Think of it like it's a library or a repository where all the patterns are delivered, all the patterns are stored. Now in the architecture reports, you have those technical design authority for those who are in this architecture community for more than 10 years, you probably understand we didn't use to have ARBs at that time. 10 15 years ago, we didn't use to have ARBs, we used to have technical design authority reviews, right, TDA reviews, we used to call.

37:18Nowadays we call it as an ARBs architecture review boards. Once a pattern has been delivered, any solution that needs an architecture review and approval, these simply ensure that whether it is meeting the approved patterns or not, right, you also go ahead and have the secure design review. This is exactly where the security architects sits in these forums to verify whether the design is an accordance to the security standards and security patterns, right, because security is also going to have their own patterns, right. How exactly these patterns are being is not only being delivering these solution capability, but also the security requirements, then you need to document these things into the architecture decision records, we call it as a ADRs architecture decision records are nothing but whether the requirements were what are the requirements, whether it is being delivered with the given patterns or not, right. One of the important elements that I have not seen a lot of organization doing it, but I personally believe this is one thing that can actually solve a massive problem into architecture embedding patterns within the pipeline.

38:28What I'm trying to say is, quantify your patterns. Let's say there is an employee authentication pattern, you want every employee to authenticate and log into your system using single sign-off, you want to do single sign-off using open id connect, sammled, whatever the technology you want to do, that's up to you, right. Now, whenever someone develops a new application, let's say internally they are developing a new application or maybe they are buying a new application, whenever they want to deploy it, whenever they want to deploy their solution, it goes through pipelines, right. And DevOps, we have CACD pipelines within these CACD pipelines, you need to embed these patterns so that it does a quick check there, whether your particular solution needs the particular required pattern or not, because whenever you want to deploy it, it checks the authentication configuration, does it have SSO enabled or not. The moment it has it, you immediately have that validation. I have not seen a lot of organization doing it, but I think this is actually going to solve a lot of problems, because I'll tell you what was the problem first of all.

39:35The problem was we had reviewed the design while the design was bad, as a security architect, you reviewed that, yeah, the design has the SSO. But how do you know if it is being implemented? The post implementation validation, how do you do that? Is there a way? There is no way you can do that. That was that is a bigger part of a problem that we have in the security architecture community that at the design phase on a piece of paper solution looks perfect. But when the solution gets implemented, there is no visibility for an architect. So how do you ensure that the solution is also enforcing these given patterns? So what do you do? You embed these patterns in the pipeline so that it actually gets enforced. You're trying to push people to shift left. That's where you're codifying these patterns into their pipeline so that whenever they push their application into production, whether it is meeting architect or patterns, single sign on encryption, data security, log in monitoring, everything is being taken care of there.

40:46That's the ideal place we all want to be. Documentation is the key. If you're not documenting it, people will probably go back and question you that, hey, how can we know that if this is the case? And we know that if this is an approved pattern or not, and communication is the enabler. What does it mean? People would not know until you communicate until you cascade that right? It's very, very important that you inform people make people aware that this is the pattern and this is exactly what we want to deliver. So this is a draw.io application. This is a wonderful element that we have for building designs and everything. I mean, I use it every day in my work and I've the I've also written a book on security architecture. All the design you would see, it's actually we have a drawn on this particular platform. It's free of cost. Now that's I think the most appealing thing from an art from a usage perspective. It's free of cost. Anyways, so what I'm trying to show you here is the particular one second, let me get a bright color. Yeah, so what I'm trying to show you here is how do we build a pattern for secure file transfer? Okay, we've been talking about secure file transfers. So think about so this is an internet. This is an external.

42:06External elements that we have we have internet. We have cloud service providers and everything all of this is think of it like a SaaS software as a service right and then we have internal system internal application internal systems that we have internal. Desktop, so what the application that are hosted in there and this is the area what we call it as. Team lacrosse, right and then we also have a private cloud think of it like it's a VPC of used AWS as an example right AWS VPC is there so. In case if there is a need of sending and receiving the file from both inside outside like ingress, egress, both. How exactly the outbound file transfer can be done so internal application dropping the files on a file transfer server on the DMZ and then in case if someone wants to pick the files here, they can actually pick up pick it up. So for example, let's say there is a particular cloud service provider, SaaS here, it wants to pick it up. There is a proper SFTP connection, the secure connection that we have, which also manages manage to do the proper secure transmission there.

43:11So it's nothing but FTP over SSH and that's how we're going to start picking up the file in case if someone wants to consume the file from outside for example this particular service provider wants to deliver the file to internal application. This is exactly how they can do it with the SFTP or PGP encryption. So we are showing the data security. We're showing the all the controls around it and here what we can do is we can even run a malware scanning. So that any kind of an inbound file that is being dropped here, nobody can pick it up unless it is being scanned successfully. Saying capability in case if you want to have your private cloud wants to consume any files from any kind of a SaaS or maybe any internal application, they can even do it for a so we have a direct connect direct connect is think of it like a kind of a VPN services in the cloud for I'm using just for AWS. In Azure in case if you're using Azure that would be express route right it's nothing but a secure integration between your own managed network.

44:17And your own private cloud right so that's where we are using this particular connectivity. So what we're doing here is in case if the your own private cloud wants to take a file from it, they can simply go and integrate with the file transfer services and they can consume the file. Or maybe you can have any of the if the file is not involved, you just want to integrate you can have some kind of an API gateway. If that particular app SaaS service wants to consume any of the services from this particular application or this particular application, they can simply integrate via API gateway API gateway are something that exposes the services through some API endpoints. So rather than letting them connect internally, you are making them connect through a particular API gate right gateways are one of the best services that we can use to manage the security for any of the integration right. In case if you think that the requirement would be for some kind of file transfers, well you can even go ahead and manage although the preference is not to use email as one of the file transfer technique, but just in case if you have to do that, you can use via SMTP servers right you want to enable the SMTP authentication secure email relay SPF configuration that center policy framework domain key identified mail.

45:40These are the security controls that you can build within your SMTP server what we are doing here is we are trying to understand if the requirement is for file transfer what are the various ways we can deliver that in a secure manner right. So this is not something what I mean this is not exactly what a pattern would look like entirely it needs to be documented with the proper problem statement tradeoffs what are we trying to deliver what are the components we are using how do we implement it everything need to be properly documented and before we start implementing it right. So the purpose of building this in a shift left where I was mentioning that you need to embed this within your particular a pipelines so that in case if there is a need of integration whether they are falling through a proper API gate or a file transfer services or not that was the whole idea behind it.