ভয় এবং ঘৃণা করা DevSecOps

আমাদের 2টি কোড বিশ্লেষক, 4টি ডায়নামিক টেস্টিং টুল, আমাদের নিজস্ব কারুশিল্প এবং 250টি স্ক্রিপ্ট ছিল৷ বর্তমান প্রক্রিয়ায় এই সমস্ত কিছুর প্রয়োজন ছিল না, তবে আপনি একবার DevSecOps বাস্তবায়ন শুরু করলে, আপনাকে শেষ পর্যন্ত যেতে হবে।

উৎস. জাস্টিন রোইল্যান্ড এবং ড্যান হারমন দ্বারা নির্মিত চরিত্রগুলি।

SecDevOps কি? DevSecOps সম্পর্কে কি? পার্থক্য কি? অ্যাপ্লিকেশন নিরাপত্তা - এটি সম্পর্কে কি? কেন ক্লাসিক পদ্ধতি আর কাজ করে না? এই সব প্রশ্নের উত্তর জানেন ইউরি শাবালিন থেকে সোর্ডফিশ নিরাপত্তা। ইউরি বিস্তারিতভাবে সবকিছুর উত্তর দেবেন এবং ক্লাসিক অ্যাপ্লিকেশন সিকিউরিটি মডেল থেকে DevSecOps প্রক্রিয়ায় স্থানান্তরের সমস্যাগুলি বিশ্লেষণ করবেন: কীভাবে সঠিকভাবে DevOps প্রক্রিয়ায় নিরাপদ উন্নয়ন প্রক্রিয়ার সংহতকরণের সাথে যোগাযোগ করা যায় এবং কিছু ভাঙতে না হয়, কীভাবে মূল পর্যায়গুলির মধ্য দিয়ে যেতে হয় নিরাপত্তা পরীক্ষার, কোন সরঞ্জামগুলি ব্যবহার করা যেতে পারে, কীভাবে সেগুলি আলাদা এবং কীভাবে সমস্যাগুলি এড়াতে সেগুলিকে সঠিকভাবে কনফিগার করা যায়।

স্পিকার সম্পর্কে: ইউরি শাবালিন - প্রতিষ্ঠানটির প্রধান নিরাপত্তা স্থপতি মো সোর্ডফিশ নিরাপত্তা. SSDL বাস্তবায়নের জন্য দায়ী, একটি একক উন্নয়ন এবং পরীক্ষার ইকোসিস্টেমে অ্যাপ্লিকেশন বিশ্লেষণ সরঞ্জামগুলির সামগ্রিক একীকরণের জন্য। তথ্য সুরক্ষায় 7 বছরের অভিজ্ঞতা। Alfa-Bank, Sberbank এবং পজিটিভ টেকনোলজিসে কাজ করেছেন, যা সফ্টওয়্যার তৈরি করে এবং পরিষেবা প্রদান করে। আন্তর্জাতিক সম্মেলন ZerONights, PHDays, RISSPA, OWASP এর স্পিকার।

অ্যাপ্লিকেশন নিরাপত্তা: এটা সম্পর্কে কি?

অ্যাপ্লিকেশন সুরক্ষা নিরাপত্তা বিভাগ যা অ্যাপ্লিকেশন নিরাপত্তার জন্য দায়ী। এটি অবকাঠামো বা নেটওয়ার্ক সুরক্ষা সম্পর্কে নয়, তবে আমরা যা লিখি এবং বিকাশকারীরা কী কাজ করে সে সম্পর্কে - এগুলি নিজেই অ্যাপ্লিকেশনটির ত্রুটি এবং দুর্বলতা।

অভিমুখ SDL বা SDLC - নিরাপত্তা উন্নয়ন জীবনচক্র - মাইক্রোসফট দ্বারা বিকশিত. ডায়াগ্রামটি ক্যানোনিকাল SDLC মডেল দেখায়, যার প্রধান কাজ হল বিকাশের প্রতিটি পর্যায়ে নিরাপত্তার অংশগ্রহণ, প্রয়োজনীয়তা থেকে শুরু করে উৎপাদন এবং প্রকাশ পর্যন্ত। মাইক্রোসফ্ট বুঝতে পেরেছিল যে প্রমের মধ্যে অনেকগুলি বাগ রয়েছে, সেগুলির মধ্যে আরও অনেকগুলি রয়েছে এবং এটি সম্পর্কে কিছু করা দরকার, এবং তারা এই পদ্ধতির প্রস্তাব করেছিল, যা ক্যানোনিকাল হয়ে ওঠে।

অ্যাপ্লিকেশান সিকিউরিটি এবং SSDL এর লক্ষ্য দুর্বলতা সনাক্ত করা নয়, যেমনটি সাধারণত বিশ্বাস করা হয়, তবে তাদের সংঘটন রোধ করা। সময়ের সাথে সাথে, মাইক্রোসফ্ট থেকে ক্যানোনিকাল পদ্ধতির উন্নতি হয়েছে, বিকশিত হয়েছে, এটির একটি গভীর বিশদ নিমজ্জন রয়েছে।

ক্যানোনিকাল SDLC বিভিন্ন পদ্ধতিতে অত্যন্ত বিস্তারিত - OpenSAMM, BSIMM, OWASP। পদ্ধতিগুলি ভিন্ন, তবে সাধারণত একই রকম।

পরিপক্কতা মডেলে নিরাপত্তা বিল্ডিং

আমি এটা সবচেয়ে পছন্দ বিএসআইএমএম - পরিপক্কতা মডেলে নিরাপত্তা বিল্ডিং. পদ্ধতির ভিত্তি হল অ্যাপ্লিকেশন নিরাপত্তা প্রক্রিয়াকে 4টি ডোমেনে বিভক্ত করা: গভর্নেন্স, ইন্টেলিজেন্স, এসএসডিএল টাচপয়েন্ট এবং স্থাপনা। প্রতিটি ডোমেনে 12টি অনুশীলন রয়েছে, যা 112টি কার্যকলাপ হিসাবে উপস্থাপন করা হয়।

প্রতিটি 112 কার্যক্রম আছে 3 পরিপক্কতা স্তর: শিক্ষানবিস, মধ্যবর্তী এবং উন্নত। আপনি বিভাগগুলিতে সমস্ত 12টি অনুশীলন অধ্যয়ন করতে পারেন, আপনার জন্য গুরুত্বপূর্ণ জিনিসগুলি নির্বাচন করতে পারেন, কীভাবে সেগুলি বাস্তবায়ন করতে হয় এবং ধীরে ধীরে উপাদানগুলি যোগ করতে পারেন, উদাহরণস্বরূপ, স্ট্যাটিক এবং গতিশীল কোড বিশ্লেষণ বা কোড পর্যালোচনা। আপনি একটি পরিকল্পনা আঁকেন এবং নির্বাচিত কার্যক্রম বাস্তবায়নের অংশ হিসাবে শান্তভাবে কাজ করুন।

কেন DevSecOps

DevOps একটি সামগ্রিক বড় প্রক্রিয়া যেখানে নিরাপত্তার যত্ন নেওয়া প্রয়োজন।

প্রাথমিকভাবে DevOps জড়িত নিরাপত্তা চেক. অনুশীলনে, নিরাপত্তা দলের সংখ্যা এখনকার তুলনায় অনেক কম ছিল, এবং তারা প্রক্রিয়াটিতে অংশগ্রহণকারী হিসাবে নয়, একটি নিয়ন্ত্রণ এবং তদারকি সংস্থা হিসাবে কাজ করেছিল যা এটির উপর দাবি করে এবং প্রকাশের শেষে পণ্যের গুণমান পরীক্ষা করে। এটি একটি ক্লাসিক পদ্ধতি যেখানে নিরাপত্তা দলগুলি উন্নয়ন থেকে একটি প্রাচীরের পিছনে ছিল এবং প্রক্রিয়াটিতে অংশ নেয়নি।

প্রধান সমস্যা হল তথ্য নিরাপত্তা উন্নয়ন থেকে পৃথক. সাধারণত এটি এক ধরনের আইবি সার্কিট এবং এতে 2-3টি বড় এবং ব্যয়বহুল সরঞ্জাম থাকে। প্রতি ছয় মাসে একবার, সোর্স কোড বা অ্যাপ্লিকেশনটি পরীক্ষা করার জন্য আসে এবং বছরে একবার পেন্টেস্ট. এই সবগুলি এই সত্যের দিকে পরিচালিত করে যে শিল্পের মুক্তির তারিখগুলি স্থগিত করা হয়েছে এবং স্বয়ংক্রিয় সরঞ্জামগুলির থেকে প্রচুর সংখ্যক দুর্বলতা বিকাশকারীর উপর পড়ে। এই সমস্তগুলি বিচ্ছিন্ন করা এবং মেরামত করা অসম্ভব, কারণ আগের ছয় মাসেও ফলাফলগুলি ভেঙে দেওয়া হয়নি এবং এখানে একটি নতুন ব্যাচ রয়েছে।

আমাদের কোম্পানির কাজ চলাকালীন, আমরা দেখতে পাই যে সমস্ত এলাকা এবং শিল্পের নিরাপত্তা বুঝতে পেরেছে যে এটি এক চাকাতে উন্নয়নের সাথে ঘোরার সময়। কর্মতত্পর. DevSecOps দৃষ্টান্তটি চটপটে উন্নয়ন পদ্ধতি, বাস্তবায়ন, সমর্থন এবং প্রতিটি প্রকাশ এবং পুনরাবৃত্তিতে অংশগ্রহণের সাথে পুরোপুরি ফিট করে।

DevSecOps-এ রূপান্তর

নিরাপত্তা উন্নয়ন জীবনচক্রের সবচেয়ে গুরুত্বপূর্ণ শব্দ "প্রক্রিয়া". সরঞ্জাম কেনার বিষয়ে চিন্তা করার আগে আপনাকে এটি বুঝতে হবে।

DevOps প্রক্রিয়ায় কেবলমাত্র সরঞ্জামগুলি অন্তর্ভুক্ত করাই যথেষ্ট নয় - প্রক্রিয়া অংশগ্রহণকারীদের মধ্যে যোগাযোগ এবং বোঝাপড়া গুরুত্বপূর্ণ।

মানুষ হাতিয়ারের চেয়ে গুরুত্বপূর্ণ

প্রায়শই একটি নিরাপদ উন্নয়ন প্রক্রিয়ার পরিকল্পনা করা একটি টুল বেছে নেওয়া এবং কেনার মাধ্যমে শুরু হয় এবং বর্তমান প্রক্রিয়ার সাথে টুলটিকে একীভূত করার প্রচেষ্টার মাধ্যমে শেষ হয়, যা প্রচেষ্টা থেকে যায়। এটি দুঃখজনক পরিণতির দিকে পরিচালিত করে, কারণ সমস্ত সরঞ্জামের নিজস্ব বৈশিষ্ট্য এবং সীমাবদ্ধতা রয়েছে।

একটি সাধারণ ঘটনা হল যখন নিরাপত্তা বিভাগ বিস্তৃত বৈশিষ্ট্য সহ একটি ভাল, ব্যয়বহুল সরঞ্জাম বেছে নেয় এবং এটি প্রক্রিয়ার মধ্যে তৈরি করার জন্য বিকাশকারীদের কাছে আসে। তবে এটি কার্যকর হয় না - প্রক্রিয়াটি এমনভাবে ডিজাইন করা হয়েছে যাতে ইতিমধ্যে কেনা একটি যন্ত্রের সীমাবদ্ধতা বর্তমান দৃষ্টান্তের সাথে খাপ খায় না।

প্রথমে, আপনি কী ফলাফল চান এবং প্রক্রিয়াটি কেমন হবে তা বর্ণনা করুন। এটি প্রক্রিয়ায় টুল এবং নিরাপত্তার ভূমিকা বুঝতে সাহায্য করবে।

যা ইতিমধ্যে ব্যবহারে আছে তা দিয়ে শুরু করুন

ব্যয়বহুল সরঞ্জাম কেনার আগে, আপনার ইতিমধ্যে কি আছে তা দেখুন। প্রতিটি কোম্পানির সুরক্ষা প্রয়োজনীয়তা রয়েছে যা বিকাশের জন্য প্রযোজ্য, সেখানে চেক, অনুপ্রবেশ পরীক্ষা রয়েছে - কেন এই সমস্তকে সবার জন্য একটি বোধগম্য এবং সুবিধাজনক আকারে রূপান্তরিত করবেন না?

সাধারণত প্রয়োজনীয়তা একটি কাগজ তালমুড যে একটি তাক উপর মিথ্যা. একটি কেস ছিল যখন আমরা কোম্পানির কাছে প্রক্রিয়াগুলি দেখতে আসি এবং তাদের সফ্টওয়্যারটির জন্য নিরাপত্তা প্রয়োজনীয়তাগুলি দেখাতে বলি৷ যে বিশেষজ্ঞ এটি করেছিলেন তিনি দীর্ঘ সময় ধরে খুঁজছিলেন:

- এখন, নোটের কোথাও একটি পথ ছিল যেখানে এই নথিটি রয়েছে।

ফলস্বরূপ, আমরা এক সপ্তাহ পরে নথি পেয়েছি।

প্রয়োজনীয়তা, চেক এবং আরও অনেক কিছুর জন্য, একটি পৃষ্ঠা তৈরি করুন, উদাহরণস্বরূপ এখানে জনতা - এটা সবার জন্য সুবিধাজনক।

ইতিমধ্যে সেখানে যা আছে তা পুনরায় ফর্ম্যাট করা এবং শুরু করতে এটি ব্যবহার করা সহজ।

নিরাপত্তা চ্যাম্পিয়ন ব্যবহার করুন

সাধারণত, 100-200 বিকাশকারীদের জন্য একটি গড় কোম্পানিতে, একজন নিরাপত্তা কর্মকর্তা আছেন যিনি বিভিন্ন ফাংশন সম্পাদন করেন এবং শারীরিকভাবে সবকিছু পরীক্ষা করার সময় পান না। এমনকি যদি সে তার যথাসাধ্য চেষ্টা করে, তবে সে একাই বিকাশের তৈরি করা সমস্ত কোড পরীক্ষা করবে না। এই ধরনের ক্ষেত্রে, একটি ধারণা তৈরি করা হয়েছে - নিরাপত্তা চ্যাম্পিয়ন.

সিকিউরিটি চ্যাম্পিয়নস হল ডেভেলপমেন্ট টিমের মধ্যে একজন ব্যক্তি যিনি আপনার পণ্যের নিরাপত্তায় আগ্রহী।

সিকিউরিটি চ্যাম্পিয়ন হল ডেভেলপমেন্ট টিমের একটি এন্ট্রি পয়েন্ট এবং একজন সিকিউরিটি ইভাঞ্জেলিস্ট সকলকে একের মধ্যে নিয়ে আসা।

সাধারণত, যখন একজন নিরাপত্তা কর্মকর্তা ডেভেলপমেন্ট টিমের কাছে আসেন এবং কোডে একটি ত্রুটি নির্দেশ করেন, তখন তিনি একটি আশ্চর্যজনক উত্তর পান:

- এবং তুমি কে? আমি তোমাকে প্রথমবার দেখছি। আমার সাথে সবকিছু ঠিক আছে - আমার সিনিয়র বন্ধু কোড রিভিউতে "আবেদন" রেখেছেন, আমরা এগিয়ে যাই!

এটি একটি সাধারণ পরিস্থিতি, কারণ সিনিয়র বা শুধুমাত্র সতীর্থদের উপর অনেক বেশি আস্থা রয়েছে যাদের সাথে বিকাশকারী ক্রমাগত কর্মক্ষেত্রে এবং কোড পর্যালোচনায় যোগাযোগ করে। যদি, একজন নিরাপত্তা প্রহরীর পরিবর্তে, নিরাপত্তা চ্যাম্পিয়ন ত্রুটি এবং পরিণতি নির্দেশ করে, তাহলে তার কথার ওজন বেশি হবে।

এছাড়াও, বিকাশকারীরা তাদের কোড যে কোনও নিরাপত্তা লোকের চেয়ে ভাল জানেন। একজন ব্যক্তির জন্য যার একটি স্ট্যাটিক বিশ্লেষণ টুলে কমপক্ষে 5টি প্রকল্প রয়েছে, সাধারণত সমস্ত সূক্ষ্মতা মনে রাখা কঠিন। নিরাপত্তা চ্যাম্পিয়নরা তাদের পণ্য জানেন: কিসের সাথে ইন্টারঅ্যাক্ট করে এবং প্রথমে কী দেখতে হবে - তারা আরও দক্ষ।

তাই নিরাপত্তা চ্যাম্পিয়ন্স বাস্তবায়ন এবং নিরাপত্তা দলের প্রভাব বিস্তার বিবেচনা করুন. চ্যাম্পিয়নের জন্য, এটিও দরকারী: একটি নতুন ক্ষেত্রে পেশাদার বিকাশ, প্রযুক্তিগত দিগন্ত প্রসারিত করা, প্রযুক্তিগত, পরিচালনা এবং নেতৃত্বের দক্ষতা পাম্প করা, বাজার মূল্য বৃদ্ধি করা। এটি সামাজিক প্রকৌশলের কিছু উপাদান, উন্নয়ন দলে আপনার "চোখ"।

পরীক্ষার পর্যায়

প্যারাডাইম 20 বাই 80 বলেছেন যে 20% প্রচেষ্টা 80% ফলাফল দেয়। এই 20% হল অ্যাপ্লিকেশন বিশ্লেষণের অনুশীলন যা স্বয়ংক্রিয় হতে পারে এবং হওয়া উচিত। এই ধরনের কার্যকলাপের উদাহরণ হল স্ট্যাটিক বিশ্লেষণ - SAST, গতিশীল বিশ্লেষণ - ডাস্ট, и ওপেন সোর্স নিয়ন্ত্রণ. আমি আপনাকে ক্রিয়াকলাপগুলি সম্পর্কে আরও বলব, সেইসাথে সরঞ্জামগুলি সম্পর্কে, আমরা সাধারণত কোন বৈশিষ্ট্যগুলির মুখোমুখি হই যখন সেগুলি প্রক্রিয়ায় প্রবর্তিত হয় এবং কীভাবে এটি সঠিকভাবে করা যায়৷

প্রধান টুল সমস্যা

আমি সেই সমস্যাগুলি হাইলাইট করব যা মনোযোগের প্রয়োজন এমন সমস্ত যন্ত্রের জন্য প্রাসঙ্গিক৷ আমি তাদের আরও বিস্তারিতভাবে বিশ্লেষণ করব যাতে আরও পুনরাবৃত্তি না হয়।

দীর্ঘ বিশ্লেষণ সময়. যদি সমস্ত পরীক্ষা এবং সমাবেশের জন্য কমিট থেকে উৎপাদনের জন্য প্রকাশের জন্য 30 মিনিট সময় লাগে, তাহলে তথ্য নিরাপত্তা পরীক্ষায় এক দিন সময় লাগবে। তাই কেউ প্রক্রিয়াটি ধীর করবে না। এই বৈশিষ্ট্যটি বিবেচনা করুন এবং সিদ্ধান্তে আঁকুন।

উচ্চ মিথ্যা নেতিবাচক বা মিথ্যা ইতিবাচক। সমস্ত পণ্য আলাদা, সমস্ত আলাদা ফ্রেমওয়ার্ক এবং তাদের নিজস্ব কোডিং শৈলী ব্যবহার করে। বিভিন্ন কোডবেস এবং প্রযুক্তিতে, সরঞ্জামগুলি মিথ্যা নেতিবাচক এবং মিথ্যা পজিটিভের বিভিন্ন স্তর দেখাতে পারে। তাই দেখুন কি আছে আপনার কোম্পানি এবং জন্য তোমার অ্যাপ্লিকেশনগুলি একটি ভাল এবং নির্ভরযোগ্য ফলাফল দেখাবে।

বিদ্যমান সরঞ্জামগুলির সাথে কোন একীকরণ নেই. আপনি ইতিমধ্যে যা ব্যবহার করছেন তার সাথে একীকরণের পরিপ্রেক্ষিতে সরঞ্জামগুলি দেখুন। উদাহরণস্বরূপ, আপনার যদি জেনকিন্স বা টিমসিটি থাকে তবে এই সফ্টওয়্যারটির সাথে সরঞ্জামগুলির একীকরণ পরীক্ষা করুন, এবং GitLab CI এর সাথে নয়, যা আপনি ব্যবহার করেন না৷

কাস্টমাইজেশনের অভাব বা অত্যধিক জটিলতা। যদি টুলের একটি API না থাকে, তাহলে কেন এটি প্রয়োজন? ইন্টারফেসে যা কিছু করা যায় তা API-এর মাধ্যমে পাওয়া উচিত। আদর্শভাবে, টুলটিতে চেক কাস্টমাইজ করার ক্ষমতা থাকা উচিত।

কোন পণ্য উন্নয়ন রোডম্যাপ. উন্নয়ন স্থির থাকে না, আমরা সর্বদা নতুন ফ্রেমওয়ার্ক এবং ফাংশন ব্যবহার করি, নতুন ভাষায় পুরানো কোড পুনরায় লিখি। আমরা নিশ্চিত করতে চাই যে আমরা যে টুলটি কিনি তা নতুন ফ্রেমওয়ার্ক এবং প্রযুক্তি সমর্থন করবে। অতএব, এটা জানা গুরুত্বপূর্ণ যে পণ্যের একটি বাস্তব এবং সঠিক আছে রোডম্যাপ উন্নয়ন

প্রক্রিয়া বৈশিষ্ট্য

সরঞ্জামগুলির বৈশিষ্ট্যগুলি ছাড়াও, উন্নয়ন প্রক্রিয়ার বৈশিষ্ট্যগুলি বিবেচনা করুন। উদাহরণস্বরূপ, উন্নয়নে হস্তক্ষেপ একটি সাধারণ ভুল। আসুন দেখি অন্যান্য বৈশিষ্ট্যগুলি কী বিবেচনা করা উচিত এবং নিরাপত্তা দলকে কী মনোযোগ দেওয়া উচিত।

যাতে উন্নয়ন ব্যাহত না হয় এবং সময়সীমা প্রকাশ, তৈরি করুন বিভিন্ন নিয়ম এবং ভিন্ন স্টপার দেখান - দুর্বলতার উপস্থিতিতে নির্মাণ প্রক্রিয়া বন্ধ করার মানদণ্ড - বিভিন্ন পরিবেশের জন্য. উদাহরণস্বরূপ, আমরা বুঝতে পারি যে বর্তমান শাখাটি একটি উন্নয়ন স্ট্যান্ড বা UAT-তে যাচ্ছে, তাই আমরা থামি না এবং বলি না:

- আপনার এখানে দুর্বলতা আছে, আপনি আর কোথাও যাবেন না!

এই মুহুর্তে, ডেভেলপারদের বলা গুরুত্বপূর্ণ যে নিরাপত্তা সংক্রান্ত সমস্যাগুলি দেখতে হবে৷

দুর্বলতার উপস্থিতি আরও পরীক্ষার জন্য বাধা নয়: ম্যানুয়াল, ইন্টিগ্রেশন বা ম্যানুয়াল। অন্যদিকে, আমাদের কোনোভাবে পণ্যের নিরাপত্তার উন্নতি করতে হবে, এবং যাতে বিকাশকারীরা নিরাপত্তা যা খুঁজে পায় তাতে স্কোর না করে। অতএব, কখনও কখনও আমরা এটি করি: স্ট্যান্ডে, যখন এটি উন্নয়ন পরিবেশে রোল আউট হয়, তখন আমরা কেবল বিকাশকে অবহিত করি:

- বন্ধুরা, আপনার সমস্যা আছে, দয়া করে তাদের দিকে মনোযোগ দিন।

UAT পর্যায়ে, আমরা আবার দুর্বলতা সম্পর্কে সতর্কতা দেখাই, এবং প্রমের প্রস্থান পর্যায়ে আমরা বলি:

"বন্ধুরা, আমরা আপনাকে বেশ কয়েকবার সতর্ক করেছি, আপনি কিছুই করেননি - আমরা আপনাকে এটি দিয়ে বের হতে দেব না।

যদি আমরা কোড এবং গতিবিদ্যা সম্পর্কে কথা বলি, তবে শুধুমাত্র সেই বৈশিষ্ট্যগুলি এবং কোডগুলির দুর্বলতাগুলি দেখানো এবং সতর্ক করা প্রয়োজন যা এই বৈশিষ্ট্যটিতে লেখা হয়েছিল। যদি বিকাশকারী বোতামটি 3 পিক্সেল দ্বারা সরান এবং আমরা তাকে বলি যে তার সেখানে একটি এসকিউএল ইনজেকশন রয়েছে এবং তাই এটিকে জরুরীভাবে ঠিক করা দরকার, এটি ভুল। এখন যা লেখা আছে তা দেখুন এবং অ্যাপ্লিকেশনটিতে যে পরিবর্তন আসে তা দেখুন।

ধরা যাক আমাদের কিছু কার্যকরী ত্রুটি রয়েছে - যেভাবে অ্যাপ্লিকেশনটি কাজ করা উচিত নয়: অর্থ স্থানান্তর করা হয় না, আপনি যখন বোতামে ক্লিক করেন, তখন পরবর্তী পৃষ্ঠায় কোন রূপান্তর হয় না বা পণ্যটি লোড হয় না। নিরাপত্তা ত্রুটি - এগুলি একই ত্রুটি, তবে অ্যাপ্লিকেশনের প্রসঙ্গে নয়, তবে সুরক্ষা।

সমস্ত সফ্টওয়্যার মানের সমস্যা নিরাপত্তা সমস্যা নয়। কিন্তু সমস্ত নিরাপত্তা সমস্যা সফটওয়্যারের মানের সাথে সম্পর্কিত। শেরিফ মনসুর, এক্সপিডিয়া।

যেহেতু সমস্ত দুর্বলতা একই ত্রুটি, সেগুলি সমস্ত উন্নয়ন ত্রুটিগুলির মতো একই জায়গায় অবস্থিত হওয়া উচিত। তাই রিপোর্ট এবং ভীতিকর পিডিএফের কথা ভুলে যান যা কেউ পড়ে না।

যখন আমি একটি উন্নয়ন সংস্থার জন্য কাজ করছিলাম, তখন আমি স্ট্যাটিক বিশ্লেষণ সরঞ্জাম থেকে একটি প্রতিবেদন পেয়েছি। আমি এটি খুললাম, ভয় পেয়েছিলাম, কফি বানিয়েছিলাম, 350 পৃষ্ঠায় পাতা দিয়েছিলাম, এটি বন্ধ করে কাজে চলে গিয়েছিলাম। বড় রিপোর্ট মৃত রিপোর্ট. সাধারণত তারা কোথাও যায় না, ইমেলগুলি মুছে যায়, ভুলে যায়, হারিয়ে যায় বা ব্যবসা বলে যে এটি ঝুঁকি নিচ্ছে।

কি করো? আমরা কেবলমাত্র নিশ্চিত করা ত্রুটিগুলিকে রূপান্তর করি যা আমরা বিকাশের জন্য সুবিধাজনক ফর্মে পেয়েছি, উদাহরণস্বরূপ, জিরার ব্যাকলগে এটি যুক্ত করি। ত্রুটিগুলিকে অগ্রাধিকার দেওয়া হয় এবং কার্যকরী ত্রুটি এবং পরীক্ষার ত্রুটিগুলির সাথে অগ্রাধিকারের ক্রম অনুসারে নির্মূল করা হয়।

স্ট্যাটিক বিশ্লেষণ - SAST

এটি দুর্বলতার জন্য কোড বিশ্লেষণ।, কিন্তু এটি SonarQube এর মত নয়। আমরা নিদর্শন বা শৈলী জন্য না শুধুমাত্র পরীক্ষা. বিশ্লেষণটি বেশ কয়েকটি পদ্ধতি ব্যবহার করে: দুর্বলতা গাছ দ্বারা, দ্বারা তথ্য প্রবাহ, কনফিগারেশন ফাইল বিশ্লেষণ করে। যে কোড নিজেই জন্য সব.

পদ্ধতির সুবিধা: বিকাশের প্রাথমিক পর্যায়ে কোডে দুর্বলতা চিহ্নিত করাযখন কোন স্ট্যান্ড এবং রেডিমেড সরঞ্জাম নেই, এবং ক্রমবর্ধমান স্ক্যান ক্ষমতা: কোডের একটি বিভাগ স্ক্যান করে যা পরিবর্তিত হয়েছে, এবং শুধুমাত্র সেই বৈশিষ্ট্য যা আমরা বর্তমানে করছি, যা স্ক্যানের সময় কমিয়ে দেয়।

Минусы প্রয়োজনীয় ভাষার জন্য সমর্থন অভাব হয়.

প্রয়োজনীয় ইন্টিগ্রেশন, যা সরঞ্জামগুলিতে থাকা উচিত, আমার বিষয়গত মতামত:

• ইন্টিগ্রেশন টুল: জেনকিন্স, টিমসিটি এবং গিটল্যাব সিআই।
• উন্নয়ন পরিবেশ: ইন্টেলিজ আইডিইএ, ভিজ্যুয়াল স্টুডিও। একজন বিকাশকারীর পক্ষে একটি অবোধ্য ইন্টারফেসে আরোহণ না করা আরও সুবিধাজনক যা এখনও মনে রাখা দরকার, তবে সমস্ত প্রয়োজনীয় সংহতকরণ এবং দুর্বলতাগুলি দেখতে যা সে তার নিজের বিকাশের পরিবেশে কর্মক্ষেত্রে ঠিক খুঁজে পেয়েছে।
• কোড পর্যালোচনা: সোনারকিউব এবং ম্যানুয়াল পর্যালোচনা।
• ত্রুটি ট্র্যাকার: জিরা এবং বাগজিলা।

ছবিটি স্ট্যাটিক বিশ্লেষণের সেরা প্রতিনিধিদের কিছু দেখায়।

এটি গুরুত্বপূর্ণ সরঞ্জাম নয়, তবে প্রক্রিয়া, তাই ওপেন সোর্স সমাধান রয়েছে যা প্রক্রিয়াটি চালানোর জন্যও ভাল।

SAST ওপেন সোর্স বিপুল সংখ্যক দুর্বলতা বা জটিল ডেটাফ্লো খুঁজে পাবে না, তবে একটি প্রক্রিয়া তৈরি করার সময় সেগুলি ব্যবহার করা যেতে পারে এবং করা উচিত। তারা বুঝতে সাহায্য করে কিভাবে প্রক্রিয়াটি তৈরি করা হবে, কে বাগের প্রতিক্রিয়া জানাবে, কে রিপোর্ট করবে, কে রিপোর্ট করবে। আপনি যদি আপনার কোডের নিরাপত্তা তৈরির প্রাথমিক পর্যায়ে কাজ করতে চান, তাহলে ওপেন সোর্স সমাধান ব্যবহার করুন।

আপনি যদি যাত্রার শুরুতে থাকেন তবে এটি কীভাবে একত্রিত হতে পারে, আপনার কাছে কিছুই নেই: না CI, না জেনকিন্স, না টিমসিটি? প্রক্রিয়া একীকরণ বিবেচনা করুন.

CVS স্তরে ইন্টিগ্রেশন

আপনার যদি Bitbucket বা GitLab থাকে তবে আপনি লেভেলে ইন্টিগ্রেশন করতে পারেন সমসাময়িক সংস্করণ সিস্টেম.

ঘটনা দ্বারা অনুরোধ টান, কমিট আপনি কোড স্ক্যান করুন এবং বিল্ড স্ট্যাটাসে দেখান যে সিকিউরিটি চেক পাস হয়েছে বা ব্যর্থ হয়েছে।

মতামত। অবশ্যই, প্রতিক্রিয়া সবসময় প্রয়োজন. আপনি যদি নিরাপত্তার দিক থেকে এটি করে থাকেন, এটি একটি বাক্সে রাখুন এবং এটি সম্পর্কে কাউকে কিছু না বলেন এবং তারপর মাসের শেষে একগুচ্ছ বাগ ফেলে দেন, এটি সঠিক নয় এবং ভাল নয়।

কোড পর্যালোচনা সিস্টেমের সাথে একীকরণ

একবার, আমরা বেশ কয়েকটি গুরুত্বপূর্ণ প্রকল্পে অ্যাপসেক প্রযুক্তিগত ব্যবহারকারীকে ডিফল্ট পর্যালোচক হিসাবে সেট করি। নতুন কোডে ত্রুটি পাওয়া গেছে বা কোন ত্রুটি নেই তার উপর নির্ভর করে, পর্যালোচক "স্বীকার" বা "কাজ প্রয়োজন" করার জন্য পুল অনুরোধে স্ট্যাটাস রাখেন - হয় সবকিছু ঠিক আছে, অথবা আপনাকে চূড়ান্ত করতে হবে এবং ঠিক কিসের সাথে লিঙ্ক করতে হবে। চূড়ান্ত করতে. যে সংস্করণটি প্রকাশিত হচ্ছে তার সাথে একীকরণের জন্য, IS পরীক্ষা পাস না হলে আমরা মার্জ অক্ষম করে দিয়েছি। আমরা ম্যানুয়াল কোড পর্যালোচনাতে এটি অন্তর্ভুক্ত করেছি, এবং প্রক্রিয়ার বাকি অংশগ্রহনকারীরা এই নির্দিষ্ট প্রক্রিয়াটির নিরাপত্তার অবস্থা দেখেছে।

সোনারকিউবের সাথে একীকরণ

অনেক আছে মানের গেট কোড মানের পরিপ্রেক্ষিতে। এটি এখানে একই - আপনি শুধুমাত্র SAST যন্ত্রের জন্য একই গেট তৈরি করতে পারেন। একই ইন্টারফেস, একই মানের গেট থাকবে, শুধুমাত্র এটি বলা হবে নিরাপত্তা গেট. এবং এছাড়াও, আপনি যদি সোনারকিউব ব্যবহার করে একটি প্রক্রিয়া সেট আপ করে থাকেন তবে আপনি সহজেই সেখানে সবকিছু একত্রিত করতে পারেন।

সিআই স্তরে একীকরণ

এখানে, এছাড়াও, সবকিছু বেশ সহজ:

• অটোটেস্টের সমতুল্য, ইউনিট পরীক্ষা।
• উন্নয়ন পর্যায় অনুসারে বিভাজন: dev, test, prod. নিয়মের বিভিন্ন সেট অন্তর্ভুক্ত করা যেতে পারে, বা বিভিন্ন ব্যর্থ শর্ত: আমরা সমাবেশ বন্ধ করি, আমরা সমাবেশ বন্ধ করি না।
• সিঙ্ক্রোনাস/অসিঙ্ক্রোনাস রান. আমরা নিরাপত্তা পরীক্ষা শেষের জন্য অপেক্ষা করছি বা আমরা অপেক্ষা করছি না। অর্থাৎ, আমরা কেবল সেগুলি চালু করি এবং এগিয়ে যাই, এবং তারপরে আমরা একটি স্ট্যাটাস পাই যে সবকিছু ভাল বা খারাপ।

এটা সব একটি নিখুঁত গোলাপী বিশ্বের. বাস্তব জীবনে, এটি হয় না, তবে আমরা চেষ্টা করি। নিরাপত্তা পরীক্ষা করার ফলাফল ইউনিট পরীক্ষার ফলাফলের অনুরূপ হওয়া উচিত।

উদাহরণস্বরূপ, আমরা একটি বড় প্রকল্প নিয়েছি এবং সিদ্ধান্ত নিয়েছি যে এখন আমরা এটিকে SAST - OK দিয়ে স্ক্যান করব। আমরা এই প্রকল্পটিকে SAST-এ স্থানান্তরিত করেছি, এটি আমাদের 20 দুর্বলতা দিয়েছে, এবং আমরা একটি দৃঢ়-ইচ্ছাকৃত সিদ্ধান্ত নিয়েছি যে সবকিছু ঠিক আছে৷ 000 দুর্বলতা আমাদের প্রযুক্তিগত ঋণ। আমরা ঋণটি একটি বাক্সে রাখব, আমরা ধীরে ধীরে তা তুলে নেব এবং ত্রুটিযুক্ত ট্র্যাকারগুলিতে বাগগুলি শুরু করব। একটি কোম্পানী ভাড়া করুন, নিজেরাই সবকিছু করুন বা নিরাপত্তা চ্যাম্পিয়নদের আমাদের সাহায্য করুন এবং প্রযুক্তিগত ঋণ কমে যাবে।

এবং নতুন কোডে সমস্ত নতুন উপস্থিত দুর্বলতাগুলিকে একটি ইউনিটে বা অটোটেস্টে ত্রুটিগুলির মতোই নির্মূল করা উচিত৷ তুলনামূলকভাবে বলতে গেলে, সমাবেশ শুরু হয়, দূরে চলে যায়, দুটি পরীক্ষা এবং দুটি নিরাপত্তা পরীক্ষা পড়ে যায়। ঠিক আছে - আমরা গিয়েছিলাম, কী ঘটেছে তা দেখেছি, একটি সংশোধন করেছি, দ্বিতীয়টি সংশোধন করেছি, পরের বার গাড়ি চালিয়েছি - সবকিছু ঠিক আছে, কোনও নতুন দুর্বলতা দেখা দেয়নি, পরীক্ষা ব্যর্থ হয়নি। যদি এই কাজটি আরও গভীর হয় এবং আপনার এটি ভালভাবে বোঝার প্রয়োজন হয়, বা দুর্বলতাগুলি ঠিক করা হুডের নীচে যা রয়েছে তার বড় স্তরগুলিকে প্রভাবিত করে: ত্রুটি ট্র্যাকারে একটি বাগ আনা হয়, এটিকে অগ্রাধিকার দেওয়া হয় এবং সংশোধন করা হয়। দুর্ভাগ্যবশত, পৃথিবী নিখুঁত নয় এবং পরীক্ষা কখনও কখনও ব্যর্থ হয়।

কোডে দুর্বলতার উপস্থিতি এবং সংখ্যার পরিপ্রেক্ষিতে একটি নিরাপত্তা গেটের একটি উদাহরণ হল একটি গুণমানের গেটের একটি অ্যানালগ।

আমরা সোনারকিউবের সাথে একীভূত করি - প্লাগইন ইনস্টল করা হয়েছে, সবকিছু খুব সুবিধাজনক এবং শীতল।

উন্নয়ন পরিবেশ একীকরণ

ইন্টিগ্রেশন বিকল্প:

• কমিটের আগেও উন্নয়ন পরিবেশ থেকে একটি স্ক্যান শুরু করা হচ্ছে।
• ফলাফল দেখুন.
• ফলাফল বিশ্লেষণ।
• সার্ভারের সাথে সিঙ্ক্রোনাইজেশন।

এইভাবে সার্ভার থেকে ফলাফল পাওয়ার মত দেখায়।

আমাদের উন্নয়ন পরিবেশে ইন্টেলিজ আইডিইএ এটি শুধুমাত্র একটি অতিরিক্ত আইটেম প্রদর্শিত হয় যা বলে যে স্ক্যানের সময় এই ধরনের দুর্বলতা পাওয়া গেছে। আপনি অবিলম্বে কোড সম্পাদনা করতে পারেন, সুপারিশ এবং দেখুন প্রবাহ গ্রাফ. এই সমস্ত বিকাশকারীর কর্মক্ষেত্রে অবস্থিত, যা খুব সুবিধাজনক - আপনাকে বাকি লিঙ্কগুলি অনুসরণ করার এবং অতিরিক্ত কিছু দেখার দরকার নেই।

Open Source

এই আমার প্রিয় বিষয়. সবাই ওপেন সোর্স লাইব্রেরি ব্যবহার করে - কেন ক্রাচ এবং সাইকেলের একটি গুচ্ছ লিখবেন যখন আপনি একটি রেডিমেড লাইব্রেরি নিতে পারেন যেখানে সবকিছু ইতিমধ্যেই বাস্তবায়িত হয়েছে?

অবশ্যই, এটি সত্য, কিন্তু লাইব্রেরিগুলিও মানুষের দ্বারা লেখা হয়, নির্দিষ্ট ঝুঁকিও অন্তর্ভুক্ত করে এবং এমন দুর্বলতাও রয়েছে যা পর্যায়ক্রমে বা ক্রমাগত রিপোর্ট করা হয়। অতএব, অ্যাপ্লিকেশন সুরক্ষার একটি পরবর্তী ধাপ রয়েছে - এটি ওপেন সোর্স উপাদানগুলির বিশ্লেষণ।

ওপেন সোর্স বিশ্লেষণ - OSA

টুলটিতে তিনটি প্রধান ধাপ রয়েছে।

লাইব্রেরিতে দুর্বলতা খোঁজা। উদাহরণস্বরূপ, টুলটি জানে যে আমরা কোনো ধরনের লাইব্রেরি ব্যবহার করছি এবং সেটি জন্য CVE বা বাগ ট্র্যাকারগুলিতে কিছু দুর্বলতা রয়েছে যা লাইব্রেরির এই সংস্করণের সাথে সম্পর্কিত। আপনি যদি এটি ব্যবহার করার চেষ্টা করেন, তাহলে টুলটি আপনাকে সতর্ক করবে যে লাইব্রেরিটি দুর্বল এবং আপনাকে অন্য সংস্করণ ব্যবহার করার পরামর্শ দেবে যেখানে কোনো দুর্বলতা নেই।

লাইসেন্স বিশুদ্ধতা বিশ্লেষণ. এটি এখনও আমাদের কাছে খুব জনপ্রিয় নয়, তবে আপনি যদি একটি বিদেশী দেশের সাথে কাজ করেন, তাহলে সেখানে আপনি পর্যায়ক্রমে একটি ওপেন সোর্স উপাদান ব্যবহার করার জন্য আক্রমণ পেতে পারেন যা ব্যবহার বা পরিবর্তন করা যায় না। লাইসেন্সকৃত লাইব্রেরির নীতি অনুযায়ী আমরা এটা করতে পারি না। অথবা, যদি আমরা এটি পরিবর্তন করে থাকি এবং ব্যবহার করি তবে আমাদের অবশ্যই আমাদের কোড পোস্ট করতে হবে। অবশ্যই, কেউ তাদের পণ্যের কোড পোস্ট করতে চায় না, তবে আপনি এটি থেকে নিজেকে রক্ষা করতে পারেন।

শিল্প পরিবেশে ব্যবহৃত উপাদানগুলির বিশ্লেষণ। একটি অনুমানমূলক পরিস্থিতি কল্পনা করুন যে আমরা শেষ পর্যন্ত বিকাশ সম্পন্ন করেছি এবং শিল্পে আমাদের মাইক্রোসার্ভিসের সর্বশেষ প্রকাশটি প্রকাশ করেছি। তিনি সেখানে আশ্চর্যজনকভাবে বাস করেন - এক সপ্তাহ, এক মাস, এক বছর। আমরা এটি সংগ্রহ করি না, আমরা নিরাপত্তা চেক পরিচালনা করি না, সবকিছু ঠিক আছে বলে মনে হচ্ছে। কিন্তু হঠাৎ করে, প্রকাশের দুই সপ্তাহ পরে, ওপেন সোর্স উপাদানে একটি গুরুতর দুর্বলতা বেরিয়ে আসে, যা আমরা এই বিশেষ সমাবেশে, শিল্প পরিবেশে ব্যবহার করি। আমরা কী এবং কোথায় ব্যবহার করি তা যদি আমরা রেকর্ড না করি, তাহলে এই দুর্বলতাটি সহজভাবে দেখা যাবে না। কিছু সরঞ্জামের লাইব্রেরিতে দুর্বলতা নিরীক্ষণ করার ক্ষমতা রয়েছে যা বর্তমানে প্রম-এ ব্যবহৃত হয়। এটা খুবই কাজের.

বৈশিষ্ট্য:

• উন্নয়নের বিভিন্ন পর্যায়ের জন্য বিভিন্ন নীতি।
• একটি শিল্প পরিবেশে উপাদান মনিটর.
• প্রতিষ্ঠানের কনট্যুরে গ্রন্থাগারের নিয়ন্ত্রণ।
• বিভিন্ন বিল্ড সিস্টেম এবং ভাষার জন্য সমর্থন।
• ডকার ইমেজ বিশ্লেষণ.

ক্ষেত্রের নেতাদের কয়েকটি উদাহরণ যারা ওপেন সোর্স বিশ্লেষণে নিযুক্ত।

একমাত্র মুক্ত নির্ভরতা পরীক্ষা OWASP থেকে। আপনি প্রথম পর্যায়ে এটি চালু করতে পারেন, এটি কীভাবে কাজ করে এবং এটি কী সমর্থন করে তা দেখুন। মূলত, এগুলি সমস্ত ক্লাউড পণ্য, বা অন-প্রিমাইজ, তবে তাদের ভিত্তির পিছনে তারা এখনও ইন্টারনেটে যায়। তারা আপনার লাইব্রেরি পাঠায় না, তবে হ্যাশ বা তাদের মান যা তারা গণনা করে এবং তাদের সার্ভারে আঙ্গুলের ছাপ পাঠায় যাতে দুর্বলতার উপস্থিতির খবর পাওয়া যায়।

প্রক্রিয়া ইন্টিগ্রেশন

পরিধি লাইব্রেরি নিয়ন্ত্রণযেগুলো বাহ্যিক উৎস থেকে ডাউনলোড করা হয়। আমাদের বাহ্যিক এবং অভ্যন্তরীণ সংগ্রহস্থল রয়েছে। উদাহরণস্বরূপ, ইভেন্ট সেন্ট্রালের মধ্যে আমাদের Nexus রয়েছে এবং আমরা নিশ্চিত করতে চাই যে আমাদের সংগ্রহস্থলের ভিতরে একটি "সমালোচনামূলক" বা "উচ্চ" অবস্থার সাথে কোনো দুর্বলতা নেই। আপনি নেক্সাস ফায়ারওয়াল লাইফসাইকেল টুল ব্যবহার করে প্রক্সি সেট আপ করতে পারেন যাতে এই ধরনের দুর্বলতাগুলি কেটে যায় এবং অভ্যন্তরীণ সংগ্রহস্থলে অন্তর্ভুক্ত না হয়।

সিআই ইন্টিগ্রেশন. অটোটেস্ট, ইউনিট পরীক্ষা এবং বিকাশের পর্যায়ে বিভাজনের সাথে একই স্তরে: dev, test, prod। প্রতিটি পর্যায়ে, আপনি যে কোনও লাইব্রেরি ডাউনলোড করতে পারেন, যে কোনও কিছু ব্যবহার করতে পারেন, তবে যদি "সমালোচনামূলক" স্ট্যাটাসের সাথে কিছু কঠিন থাকে তবে আপনার সম্ভবত প্রোমে প্রবেশের পর্যায়ে বিকাশকারীদের দৃষ্টি আকর্ষণ করা উচিত।

আর্টিফ্যাক্ট ইন্টিগ্রেশন: নেক্সাস এবং জেফ্রগ।

উন্নয়ন পরিবেশে একীকরণ। আপনার বেছে নেওয়া সরঞ্জামগুলির উন্নয়ন পরিবেশের সাথে একীকরণ হওয়া উচিত। বিকাশকারীর অবশ্যই তার কর্মক্ষেত্র থেকে স্ক্যান ফলাফলগুলিতে অ্যাক্সেস থাকতে হবে, বা CVS-এ এটি করার আগে দুর্বলতার জন্য কোডটি স্ক্যান করার এবং পরীক্ষা করার ক্ষমতা থাকতে হবে।

সিডি ইন্টিগ্রেশন। এটি একটি দুর্দান্ত বৈশিষ্ট্য যা আমি সত্যিই পছন্দ করি এবং যার সম্পর্কে আমি ইতিমধ্যেই কথা বলেছি - একটি শিল্প পরিবেশে নতুন দুর্বলতার উত্থান পর্যবেক্ষণ। এটা এই মত কাজ করে.

আমাদের আছে পাবলিক উপাদান সংগ্রহস্থল - বাইরে কিছু সরঞ্জাম এবং আমাদের অভ্যন্তরীণ সংগ্রহস্থল। আমরা চাই শুধুমাত্র বিশ্বস্ত উপাদান এতে থাকুক। একটি অনুরোধ প্রক্সি করার সময়, আমরা পরীক্ষা করি যে ডাউনলোড করা লাইব্রেরিতে কোনো দুর্বলতা নেই। যদি এটি নির্দিষ্ট কিছু নীতির অধীনে পড়ে যা আমরা সেট করি এবং ডেভেলপমেন্টের সাথে অগত্যা সমন্বয় করি, তাহলে আমরা এটি আপলোড করি না এবং আমরা অন্য সংস্করণ ব্যবহার করার জন্য তিরস্কার পাই। তদনুসারে, যদি লাইব্রেরিতে সত্যিই সমালোচনামূলক এবং খারাপ কিছু থাকে, তবে বিকাশকারী ইনস্টলেশন পর্যায়েও লাইব্রেরি পাবেন না - তাকে উচ্চ বা নিম্ন সংস্করণ ব্যবহার করতে দিন।

• নির্মাণের সময়, আমরা পরীক্ষা করি যে কেউ খারাপ কিছু স্লিপ করেনি, সমস্ত উপাদান নিরাপদ এবং কেউ ফ্ল্যাশ ড্রাইভে বিপজ্জনক কিছু নিয়ে আসেনি।
• আমাদের সংগ্রহস্থলে শুধুমাত্র বিশ্বস্ত উপাদান আছে।
• মোতায়েন করার সময়, আমরা আবার প্যাকেজটি নিজেই পরীক্ষা করি: যুদ্ধ, জার, ডিএল বা ডকার ইমেজ যে এটি নীতির সাথে মেনে চলে।
• শিল্প পরিবেশে প্রবেশ করার সময়, আমরা শিল্প পরিবেশে কী ঘটছে তা পর্যবেক্ষণ করি: সমালোচনামূলক দুর্বলতাগুলি উপস্থিত হয় বা প্রদর্শিত হয় না।

গতিশীল বিশ্লেষণ - DAST

গতিশীল বিশ্লেষণ সরঞ্জামগুলি আগে যা বলা হয়েছে তার থেকে মৌলিকভাবে আলাদা। এটি অ্যাপ্লিকেশনটির সাথে ব্যবহারকারীর কাজের এক ধরণের অনুকরণ। যদি এটি একটি ওয়েব অ্যাপ্লিকেশন হয়, তাহলে আমরা ক্লায়েন্টের কাজের অনুকরণ করে অনুরোধ পাঠাই, সামনের বোতামগুলিতে ক্লিক করুন, ফর্ম থেকে কৃত্রিম ডেটা পাঠাই: অ্যাপ্লিকেশনটি কীভাবে কাজ করে এবং বহিরাগত প্রক্রিয়া করে তা দেখতে বিভিন্ন এনকোডিং-এ উদ্ধৃতি, বন্ধনী, অক্ষর। তথ্য

একই সিস্টেম আপনাকে ওপেন সোর্সে টেমপ্লেট দুর্বলতা পরীক্ষা করার অনুমতি দেয়। যেহেতু DAST জানে না আমরা কোন ওপেন সোর্স ব্যবহার করছি, তাই এটি কেবল "দূষিত" প্যাটার্ন ছুড়ে দেয় এবং সার্ভারের প্রতিক্রিয়া বিশ্লেষণ করে:

- হ্যাঁ, এখানে একটি ডিসিরিয়ালাইজেশন সমস্যা আছে, কিন্তু এখানে নয়।

এর মধ্যে বড় ঝুঁকি রয়েছে, কারণ আপনি যদি এই নিরাপত্তা পরীক্ষাটি একই স্ট্যান্ডে পরিচালনা করেন যার সাথে পরীক্ষকরা কাজ করেন, তাহলে অপ্রীতিকর ঘটনা ঘটতে পারে।

• অ্যাপ্লিকেশন সার্ভার নেটওয়ার্কে উচ্চ লোড.
• কোন ইন্টিগ্রেশন.
• বিশ্লেষণকৃত অ্যাপ্লিকেশনের সেটিংস পরিবর্তন করার ক্ষমতা।
• প্রয়োজনীয় প্রযুক্তির জন্য কোন সমর্থন নেই.
• সেট করার অসুবিধা।

আমরা যখন অবশেষে অ্যাপস্ক্যান চালু করেছি তখন আমাদের একটি পরিস্থিতি ছিল: আমরা দীর্ঘ সময়ের জন্য অ্যাপ্লিকেশনটিতে অ্যাক্সেস বন্ধ করে দিয়েছি, 3টি অ্যাকাউন্ট পেয়েছি এবং আনন্দিত হয়েছি - অবশেষে, আমরা সবকিছু পরীক্ষা করব! আমরা একটি স্ক্যান চালু করেছি, এবং অ্যাপস্ক্যান প্রথম যে কাজটি করেছিল তা হল অ্যাডমিন প্যানেলে প্রবেশ করা, সমস্ত বোতাম ছিদ্র করা, অর্ধেক ডেটা পরিবর্তন করা এবং তারপরে সার্ভারটিকে সম্পূর্ণরূপে মেরে ফেলা। মেইল ফর্ম-অনুরোধ. পরীক্ষার সাথে উন্নয়ন বলেছেন:

"বন্ধুরা, আপনি কি আমার সাথে মজা করছেন?! আমরা আপনাকে হিসাব দিয়েছি, এবং আপনি স্ট্যান্ড করা!

সম্ভাব্য ঝুঁকি বিবেচনা করুন. আদর্শভাবে, তথ্য নিরাপত্তা পরীক্ষার জন্য একটি পৃথক স্ট্যান্ড প্রস্তুত করুন, যা পরিবেশের বাকি অংশ থেকে অন্তত কোনো না কোনোভাবে বিচ্ছিন্ন হবে এবং শর্তসাপেক্ষে অ্যাডমিন প্যানেলটি পরীক্ষা করুন, বিশেষত ম্যানুয়াল মোডে। এটি একটি পেন্টেস্ট - প্রচেষ্টার অবশিষ্ট শতাংশ যা আমরা এখন বিবেচনা করছি না।

এটি বিবেচনা করা উচিত যে আপনি এটিকে লোড পরীক্ষার একটি অ্যানালগ হিসাবে ব্যবহার করতে পারেন। প্রথম পর্যায়ে, আপনি 10-15 থ্রেডে গতিশীল স্ক্যানার চালু করতে পারেন এবং দেখতে পারেন কি হয়, তবে সাধারণত, অনুশীলন দেখায়, কিছুই ভাল হয় না।

কিছু সম্পদ যা আমরা সাধারণত ব্যবহার করি।

মূল্য হাইলাইট বার্প স্যুট যেকোনো নিরাপত্তা পেশাদারের জন্য "সুইস ছুরি"। সবাই এটি ব্যবহার করে এবং এটি খুব সুবিধাজনক। এন্টারপ্রাইজ সংস্করণের একটি নতুন ডেমো সংস্করণ এখন প্রকাশিত হয়েছে। যদি আগে এটি প্লাগইনগুলির সাথে শুধুমাত্র একটি স্ট্যান্ড একা ইউটিলিটি ছিল, এখন ডেভেলপাররা অবশেষে একটি বড় সার্ভার তৈরি করছে যা থেকে বেশ কয়েকটি এজেন্ট পরিচালনা করা সম্ভব হবে। এটি দুর্দান্ত, আমি আপনাকে এটি চেষ্টা করার পরামর্শ দিই।

প্রক্রিয়া ইন্টিগ্রেশন

ইন্টিগ্রেশন বেশ ভাল এবং সহজ: সফল ইনস্টলেশনের পরে স্ক্যান শুরু করুন স্ট্যান্ড উপর অ্যাপ্লিকেশন এবং সফল ইন্টিগ্রেশন পরীক্ষার পরে স্ক্যানিং.

যদি ইন্টিগ্রেশন কাজ না করে বা স্টাব এবং মক ফাংশন থাকে তবে এটি অর্থহীন এবং অকেজো - আমরা যে প্যাটার্ন পাঠাই না কেন, সার্ভার এখনও একইভাবে প্রতিক্রিয়া জানাবে।

• আদর্শভাবে, একটি পৃথক পরীক্ষা বেঞ্চ।
• পরীক্ষার আগে, লগইন ক্রম লিখুন।
• প্রশাসনিক ব্যবস্থার পরীক্ষা শুধুমাত্র ম্যানুয়াল।

প্রক্রিয়া

সাধারণভাবে প্রক্রিয়া সম্পর্কে এবং বিশেষ করে প্রতিটি টুলের কাজ সম্পর্কে একটু সাধারণীকৃত। সমস্ত অ্যাপ্লিকেশন আলাদা - একটি গতিশীল বিশ্লেষণের সাথে আরও ভাল কাজ করে, অন্যটি স্ট্যাটিক বিশ্লেষণের সাথে, তৃতীয়টি ওপেনসোর্স বিশ্লেষণের সাথে, পেন্টেস্ট বা অন্য কিছু, উদাহরণস্বরূপ, এর সাথে ইভেন্টগুলি Waf.

প্রতিটি প্রক্রিয়া নিয়ন্ত্রণ করা প্রয়োজন।

প্রক্রিয়াটি কীভাবে কাজ করে এবং কোথায় এটিকে উন্নত করা যেতে পারে তা বোঝার জন্য, উৎপাদন মেট্রিক্স, টুলস থেকে মেট্রিক এবং ত্রুটিযুক্ত ট্র্যাকার সহ আপনি যা কিছু পেতে পারেন তার থেকে মেট্রিক্স সংগ্রহ করতে হবে।

কোন তথ্য সহায়ক. এই বা সেই টুলটি কোথায় ভালভাবে ব্যবহার করা হয়, যেখানে প্রক্রিয়াটি বিশেষভাবে স্তব্ধ হয় সেদিকে বিভিন্ন বিভাগে খোঁজ করা প্রয়োজন। সময়ের উপর ভিত্তি করে প্রক্রিয়াটি কোথায় উন্নত করা যায় তা দেখার জন্য এটি উন্নয়ন প্রতিক্রিয়া সময় দেখার মূল্য হতে পারে। যত বেশি ডেটা, উপরের স্তর থেকে প্রতিটি প্রক্রিয়ার বিবরণে তত বেশি কাট তৈরি করা যেতে পারে।

যেহেতু সমস্ত স্ট্যাটিক এবং ডাইনামিক বিশ্লেষকদের নিজস্ব API আছে, তাদের নিজস্ব লঞ্চ পদ্ধতি, নীতি, কিছুর সময়সূচী আছে, অন্যদের নেই - আমরা একটি টুল লিখছি অ্যাপসেক অর্কেস্ট্রেটর, যা আপনাকে পণ্য থেকে সম্পূর্ণ প্রক্রিয়ার জন্য একটি একক এন্ট্রি পয়েন্ট করতে এবং এক বিন্দু থেকে এটি পরিচালনা করতে দেয়।

ম্যানেজার, ডেভেলপার এবং সিকিউরিটি ইঞ্জিনিয়ারদের একটি এন্ট্রি পয়েন্ট থাকে যেখান থেকে তারা দেখতে পারে কি চলছে, কনফিগার করতে এবং স্ক্যান চালাতে, স্ক্যানের ফলাফল পেতে এবং প্রয়োজনীয়তা জমা দিতে পারে। আমরা কাগজের টুকরো থেকে দূরে সরে যাওয়ার চেষ্টা করি, উন্নয়ন ব্যবহার করে এমন সবকিছুকে মানুষের মধ্যে অনুবাদ করার চেষ্টা করি - স্থিতি এবং মেট্রিক্সের সাথে সঙ্গমে পৃষ্ঠাগুলি, জিরাতে ত্রুটি বা বিভিন্ন ত্রুটি ট্র্যাকারে, বা CI/CD-এ একটি সিঙ্ক্রোনাস/অসিঙ্ক্রোনাস প্রক্রিয়ার মধ্যে এম্বেড করা।

কী Takeaways

টুল কোন ব্যাপার না. প্রথমে প্রক্রিয়া সম্পর্কে চিন্তা করুন, তারপর সরঞ্জামগুলি বাস্তবায়ন করুন। সরঞ্জামগুলি ভাল, কিন্তু ব্যয়বহুল, তাই আপনি প্রক্রিয়াটি দিয়ে শুরু করতে পারেন এবং উন্নয়ন এবং সুরক্ষার মধ্যে মিথস্ক্রিয়া এবং বোঝাপড়াকে সূক্ষ্ম সুর করতে পারেন৷ নিরাপত্তার দৃষ্টিকোণ থেকে, একটি সারিতে সবকিছু "বন্ধ" করার দরকার নেই৷ উন্নয়নের দৃষ্টিকোণ থেকে, যদি উচ্চতর মেগা সুপার ক্রিটিকাল কিছু থাকে, তবে এটি অবশ্যই বাদ দিতে হবে, এবং সমস্যাটি বন্ধ করতে হবে না। .

পন্য মান - সাধারণ লক্ষ্য নিরাপত্তা এবং উন্নয়ন উভয়ই। আমরা একটি জিনিস করি, আমরা নিশ্চিত করার চেষ্টা করি যে সবকিছু সঠিকভাবে কাজ করে এবং কোনও সুনামগত ঝুঁকি এবং আর্থিক ক্ষতি না হয়। এই কারণেই আমরা যোগাযোগ স্থাপন এবং পণ্যটিকে আরও ভাল করার জন্য DevSecOps, SecDevOps-এর পদ্ধতির প্রচার করি।

ইতিমধ্যে যা আছে তা দিয়ে শুরু করুন: প্রয়োজনীয়তা, স্থাপত্য, আংশিক চেক, প্রশিক্ষণ, নির্দেশিকা। অবিলম্বে সমস্ত প্রকল্পে সমস্ত অনুশীলন প্রয়োগ করার প্রয়োজন নেই - পুনরাবৃত্তিমূলকভাবে সরান. কোন একক মান নেই পরীক্ষা এবং বিভিন্ন পন্থা এবং সমাধান চেষ্টা করুন।

IS ত্রুটি এবং কার্যকরী ত্রুটির মধ্যে সমান চিহ্ন.

সবকিছু স্বয়ংক্রিয় করুনযে চলন্ত হয়. নড়াচড়া, সরানো এবং স্বয়ংক্রিয় না যে কিছু. যদি কিছু হাত দ্বারা করা হয়, এটি প্রক্রিয়াটির একটি ভাল অংশ নয়। সম্ভবত এটি পুনর্বিবেচনা করা এবং এটিকে স্বয়ংক্রিয় করাও মূল্যবান।

আইবি দলের আকার ছোট হলে- নিরাপত্তা চ্যাম্পিয়ন ব্যবহার করুন.

সম্ভবত আমি যা বলেছি তা আপনার জন্য উপযুক্ত হবে না এবং আপনি আপনার নিজস্ব কিছু নিয়ে আসবেন - এবং এটি ভাল। কিন্তু আপনার প্রক্রিয়ার প্রয়োজনীয়তার উপর ভিত্তি করে সরঞ্জাম নির্বাচন করুন. সম্প্রদায় কী বলে যে এই সরঞ্জামটি খারাপ এবং এটি ভাল তা দেখুন না। সম্ভবত এটি আপনার পণ্যের কাছাকাছি অন্য উপায় হবে.

টুল প্রয়োজনীয়তা.

• কম ফলস পজিটিভ।
• পর্যাপ্ত বিশ্লেষণ সময়।
• ব্যবহার সহজ।
• ইন্টিগ্রেশনের প্রাপ্যতা।
• পণ্য উন্নয়ন রোডম্যাপ বোঝা।
• টুল কাস্টমাইজ করার ক্ষমতা।

ইউরির রিপোর্টটি DevOpsConf 2018-এ সেরাদের মধ্যে একটি হিসেবে বেছে নেওয়া হয়েছে। আরও আকর্ষণীয় ধারণা এবং ব্যবহারিক ক্ষেত্রে পরিচিত হতে, 27 এবং 28 মে Skolkovo-এ আসুন DevOpsConf মধ্যে উৎসব RIT++. আরও ভাল, আপনি যদি আপনার অভিজ্ঞতা ভাগ করতে ইচ্ছুক হন তবে আবেদন 21শে এপ্রিলের মধ্যে আপনার প্রতিবেদন জমা দিন।

উত্স: www.habr.com