What should be important to setup a new organisation working on app development in order to ensure complete security and compliance?
director of faculty and student technology in Education, 5,001 - 10,000 employees
Early and frequent peer code reviews and regular conversations at the team level about code security practices. Make it a part of the culture.CISO in Healthcare and Biotech, 2 - 10 employees
Training for the development team on basic security practices - never trust inputs, include verbose logging into the code for better troubleshooting, conduct threat modeling into the design, and have solid code validation to spot common coding errors. Understand the OWASP Top Ten issues.Never trust open source - it's free, like a puppy. Conduct code reviews, promote secure code, and leverage common, well known and well documented callable functions.
Remember that security is different from compliance; do not confuse them. Promote solid change management processes, with rollback as needed. Good luck, have fun, and celebrate successes.
Chief Information Officer in Software, 11 - 50 employees
How you approach basic security and compliance will depend upon what the application(s) you are building are intended to do, what industry you are targeting, what country(ies) you are targeting to offer or sell the application(s), the infrastructure you are planning to deploy to, the networks you will connect to, and whether they are to be internet facing, intranet facing, or extranet facing.Of course there are basic security considerations you can take for any and all WAN/MAN/LORA based applications for security, once you define what WAN provisions you will or will not support.
Below are listed some very basic considerations you need to have a cursory understanding of before you start fleshing our the requirements for the application or services you are considering.
SECURITY BASED CONSIDERATIONS
1. Find a list of standard security recommendation standards you can use as basic checklist
There are many to choose from. Here is an example published by the Canadian government
https://www.cyber.gc.ca/en/guidance/security-considerations-your-website-itsm60005
2. If you will be choosing a public cloud provider (AWS, Azure, GPC, etc.) determine whether you want to consider managed services over basic services. If managed services, many of the security requirements are selectable from the type of managed services you are considering.
3. Container based services (Kubernetes, Open Stack, Elastic Containers, Compute Container Platforms). Determine what these container managed environments support out of the box and if there are preferred solutions they work best with.
4. Basic Data in transit / Data at rest provisions. Depending upon the database chosen and the types of data you will be collecting, will determine security of data in transit (CRUD operations) verses column and row level encryption. If the database will have role based access, you will need to allow role based access limiting CRUD operations at the API level or at database access level. If you want to maximize database security, provide database access only at the most secure level and provide API only access for anyone outside Administrator Access. The same is true for any and all ESB type access.
5. Service orchestration: Use at minimum, a security token based authentication for services, even behind the firewalls for service to service interactions. This way, even if your entry level security is compromised, the remainder of the services could stop progression and compromises of all downstream systems.
COMPLIANCE BASED CONSIDERATIONS (Federal, State or Province Local)
This is going to be industry specific as well as country, state or province, and locality specific. You will have to familiarize yourself with the compliance and regulatory requirements your applications will required, based upon the type of data that you will be working with.
Applications created in the US, despite type of applications (see below) can be vastly different from other countries. If you plan to distribute your application(s) to other countries, make sure to cross check requirements with other countries.
The following considerations are federal compliance type examples using United States Government Compliance. Please note, these are only general guidelines or potential compliance perspectives your application may or may not need to comply with.
1. Personal Data: For instance in the US, you will probably, at minimum, have to apply Privacy Act compliance (Privacy Act of 1974, 5 U.S.C. § 552a). Probably 85% of applications collect some types of data that should comply with this simple compliance act.
2. Financial Transaction Data: Credit Card Type data requires at minimum, compliance with what is known as PCI, which requires 12 basic steps for compliance. If your applications also store credit history information or any banking type operations, you may be required to comply with Sarbanes/Oxley (SOX), as well as Dodd/Frank Act. Of course, if your apps are integrating with or handling these types of transactions, you are probably already familiar, but it is imperative that if your apps must comply with these standards, you understand the levels and compliance standards you must comply with.
3. Personal Health data (Employees or other). Any health related data must comply with the Health Insurance Portability and Accountability Act of 1996 (HIPAA).
4. Rail and Transportation related Data (the FRA covers compliance and regulation of Rail Data. The US DOT may have other requirements around transportation data, especially around sensitive shipment data or HAZMAT type loads and collection and dissemination of that data.
5. State Laws: Some states have additional compliance regulations above the federal level. This is especially true with personal identification and financial transaction data. Need to check to make sure if you operate in these states, you are compliant.
COMPLIANCE BASED CONSIDERATIONS (Corporate)
Your Corporations may have their own compliance as well as any customers you are offering your application(s) stacks to. This may require an audit/review type process.
SLA compliance is another factor. If you are offering your applications or services as SaaS /PaaS or other, you will invariably have contractual SLAs around compliance. They may have special security or compliance perspectives or they may not. If they do, make sure you are compliant.
Hope this helps with identifying some of the considerations that may be needed based upon the specific types of applications or services you may be standing up.
Director of IT in Software, 201 - 500 employees
There are a lot of areas that need to be covered to have proper security. If I have to pick one, it will be code repository scanning especially applying dynamic application security testing (DAST), and interactive application security testing (IAST).Content you might like
CTO in Software, 201 - 500 employees
Without a doubt - Technical Debt! It's a ball and chain that creates an ever increasing drag on any organization, stifles innovation, and prevents transformation.ISSO and Director of the IRU in Healthcare and Biotech, 10,001+ employees
I would definitely suggest this based of how you categorize your types of data/systems and information being stored in certain parts of your data center. I think it’s really dependent on the size of your organization and ...read moreProduction45%
Backup65%
Replication33%
Non-production DBs (Dev, Training, QA, etc.)30%
215 PARTICIPANTS
Yes41%
No15%
Sometimes42%
8254 PARTICIPANTS
Develop a comprehensive security plan: Start by creating a comprehensive security plan that covers all aspects of your app's development and deployment. This includes data storage and transmission, user authentication and authorization, encryption, security testing, and more. Ensure that your security plan is regularly reviewed and updated to account for new threats and vulnerabilities.
Follow secure coding practices: Ensure that all developers follow secure coding practices to minimize vulnerabilities in the app. This includes using secure coding languages and libraries, avoiding hard-coded passwords and other sensitive information, and using encryption and authentication techniques wherever necessary.
Use secure hosting and infrastructure: Host your app on a secure infrastructure that provides protection against threats like DDoS attacks, malware, and unauthorized access. Ensure that all servers and databases are regularly patched and updated to prevent known vulnerabilities.
Conduct regular security assessments and testing: Conduct regular security assessments and penetration testing to identify vulnerabilities in your app and infrastructure. This helps you to detect and address vulnerabilities before they are exploited by attackers.
Follow regulatory and compliance requirements: Ensure that your app meets all regulatory and compliance requirements, such as HIPAA, GDPR, or PCI-DSS, depending on the type of data your app handles. This includes implementing appropriate privacy and security controls, maintaining audit logs, and reporting data breaches if they occur.
Implement user privacy controls: Implement user privacy controls in your app, such as the ability to opt-out of data collection and sharing, and ensure that users are informed of how their data is being used and shared.
Provide regular security awareness training: Provide regular security awareness training for all employees and contractors involved in the development and deployment of your app. This helps to ensure that everyone understands the importance of security and compliance and knows how to identify and report security incidents.